-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
struct subfield and list element type #1449
Conversation
Conformance comparison report-Cross Engine
Number failing in both: 228 Number passing in legacy engine but fail in eval engine: 313 Number failing in legacy engine but pass in eval engine: 207 Conformance comparison report-Cross Commit-LEGACY
Number failing in both: 435 Number passing in Base (607c4c0) but now fail: 0 Number failing in Base (607c4c0) but now pass: 1 Click here to see
Conformance comparison report-Cross Commit-EVAL
Number failing in both: 541 Number passing in Base (607c4c0) but now fail: 1 Number failing in Base (607c4c0) but now pass: 3 Click here to see
Click here to see
|
partiql-parser/src/main/kotlin/org/partiql/parser/internal/PartiQLParserDefault.kt
Outdated
Show resolved
Hide resolved
partiql-parser/src/main/kotlin/org/partiql/parser/internal/PartiQLParserDefault.kt
Show resolved
Hide resolved
partiql-parser/src/test/kotlin/org/partiql/parser/internal/PartiQLParserDDLTests.kt
Show resolved
Hide resolved
Co-authored-by: Alan Cai <[email protected]>
| datatype=DOUBLE PRECISION # TypeAtomic | ||
| datatype=(CHARACTER|CHAR|FLOAT|VARCHAR) ( PAREN_LEFT arg0=LITERAL_INTEGER PAREN_RIGHT )? # TypeArgSingle | ||
| CHARACTER VARYING ( PAREN_LEFT arg0=LITERAL_INTEGER PAREN_RIGHT )? # TypeVarChar | ||
| datatype=(DECIMAL|DEC|NUMERIC) ( PAREN_LEFT arg0=LITERAL_INTEGER ( COMMA arg1=LITERAL_INTEGER )? PAREN_RIGHT )? # TypeArgDouble | ||
| datatype=(TIME|TIMESTAMP) ( PAREN_LEFT precision=LITERAL_INTEGER PAREN_RIGHT )? (WITH TIME ZONE)? # TypeTimeZone | ||
| datatype=(STRUCT|TUPLE) (ANGLE_LEFT structAttr ( COMMA structAttr )* ANGLE_RIGHT) # TypeStruct |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is going to the 1.0
, do we want to flesh out the open/close and other struct constraints in the syntax now; if not, how can we avoid backward incompatibility when we introduce the syntax for those?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my mental model, I think that using SQL's CREATE TABLE
get us a bag of closed struct. For creating shapes that is unique to PartiQL, a bag of opened struct, a bag of integers, etc. we can consider vend out a PartiQL specific syntax (i.e., CREATE SHAPE ?) for those.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just like other deviations from Hive DDL, we may have to support such use-cases within the same syntax; let's discuss further about this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding the summary of our discussion in an example here for posterity:
CREATE TABLE [OPEN] Foo (
s STRUCT<a: INT, b:STRING> OPEN,
)
partiql-parser/src/test/kotlin/org/partiql/parser/internal/PartiQLParserDDLTests.kt
Outdated
Show resolved
Hide resolved
partiql-parser/src/main/kotlin/org/partiql/parser/internal/PartiQLParserDefault.kt
Outdated
Show resolved
Hide resolved
partiql-parser/src/test/kotlin/org/partiql/parser/internal/PartiQLParserDDLTests.kt
Show resolved
Hide resolved
partiql-parser/src/test/kotlin/org/partiql/parser/internal/PartiQLParserDDLTests.kt
Outdated
Show resolved
Hide resolved
partiql-parser/src/test/kotlin/org/partiql/parser/internal/PartiQLParserDDLTests.kt
Outdated
Show resolved
Hide resolved
partiql-parser/src/main/kotlin/org/partiql/parser/internal/PartiQLParserDefault.kt
Show resolved
Hide resolved
Co-authored-by: Alan Cai <[email protected]>
Delete NEQ Token
* Revert "V1 ddl extended keyword (#1455)" This reverts commit 2879f3a * Revert "struct subfield and list element type (#1449)" This reverts commit 23f6fee * Revert "run apiDump (#1447)" This reverts commit 607c4c0 * Revert "Support parsing for attribute and tuple level constraint (#1442)" This reverts commit abfc58d * fix post-revert build * submodule
Relevant Issues
Description
IS
,CAST
, etc, we do not allow struct type with field declaration or list type with element type declaration at the moment.Other Information
Updated Unreleased Section in CHANGELOG: [YES/NO]
Any backward-incompatible changes? [YES/NO]
errors for users that are using our public APIs or the entities that have
public
visibility in our code-base. >Any new external dependencies? [YES/NO]
Do your changes comply with the Contributing Guidelines
and Code Style Guidelines? [YES/NO]
License Information
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.