You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 27, 2023. It is now read-only.
User MISSING as in <<{'id': INT, 'name': STRING, 'age': MISSING}>>—this appears to be wrong because it conflicts with Tuple constructors as it has been defined by PartiQL Specification — Section 6.1.1, 2019
Use NULL as in <<{'id': INT, 'name': STRING, 'age': NULL}>>—this can be a viable option; this allows to further perform the schema inference if the derived schema is dependent on this schema (E.g., in a sub-query).
Elide the attribute as in <<{'id': INT, 'name': STRING}>>—this can also be a valid option but it may result in some information loss if this schema is being used to further inferring the schema of the query.
For now, we decide to go with the NULL option pending RFC specification.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
According to the findings by the experimental implementation work for Schema Inferencer In PartiQL Rust the following questions need to get answered by the PartiQL Type System spec. work:
Case 1
Let
customers
be a closed Schema. InPermissive
typing mode what should be the output schema of the following query?Some Intuitive options:
MISSING
as in<<{'id': INT, 'name': STRING, 'age': MISSING}>>
—this appears to be wrong because it conflicts with Tuple constructors as it has been defined by PartiQL Specification — Section 6.1.1, 2019NULL
as in<<{'id': INT, 'name': STRING, 'age': NULL}>>
—this can be a viable option; this allows to further perform the schema inference if the derived schema is dependent on this schema (E.g., in a sub-query).<<{'id': INT, 'name': STRING}>>
—this can also be a valid option but it may result in some information loss if this schema is being used to further inferring the schema of the query.For now, we decide to go with the
NULL
option pending RFC specification.See @jpschorr comment: partiql/partiql-lang-rust#399
Beta Was this translation helpful? Give feedback.
All reactions