[SPARK][SQL] Block constraints in CTAS/RTAS at parser level#54454
[SPARK][SQL] Block constraints in CTAS/RTAS at parser level#54454yyanyy wants to merge 1 commit intoapache:masterfrom
Conversation
|
Also looked into updating this on grammar level (e.g. change .g4) files but decided to go with this approach as grammar level changes would require refactoring of either splitting create table and CTAS, or splitting tableElementList and code duplication in visit pattern; in comparison, the current approach follows established pattern (e.g. partition column check) and is much smaller. |
| ExpectedContext(fragment = sql2, start = 0, stop = 61)) | ||
| } | ||
|
|
||
| test("CTAS statement with constraints") { |
There was a problem hiding this comment.
Let's move the test cases to ConstraintParseSuiteBase
30402a2 to
eabd0b3
Compare
| comparePlans(parsed, expected) | ||
| } | ||
|
|
||
| test("CTAS with constraints is not allowed") { |
There was a problem hiding this comment.
hmmm, the same test will be run 4 times. If it is hard to avoid that, let's revert and use the original plan resolution suite
There was a problem hiding this comment.
sounds good; an alternative would be to parameterized the constraint definition string per subclass extending this base class and keep tests here, but indeed it will still result in many more test runs and feels unnecessarily complex for a simple change like this...
The grammar accepts constraint specifications (PRIMARY KEY, UNIQUE, CHECK, FOREIGN KEY) in CREATE TABLE AS SELECT and REPLACE TABLE AS SELECT, but the execution layer silently drops them. Neither the ANSI SQL standard nor PostgreSQL supports this syntax — the SQL standard makes table element lists and AS subquery clauses mutually exclusive. Block this at the parser level, consistent with existing CTAS/RTAS checks for schema columns and partition column types. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
eabd0b3 to
a1bd9a5
Compare
What changes were proposed in this pull request?
The grammar accepts constraint specifications (PRIMARY KEY, UNIQUE, CHECK, FOREIGN KEY) in CREATE TABLE AS SELECT and REPLACE TABLE AS SELECT, but the execution layer silently drops them. Neither the ANSI SQL standard nor PostgreSQL supports this syntax - the SQL standard makes table element lists and AS subquery clauses mutually exclusive. Block this at the parser level, consistent with existing CTAS/RTAS checks for schema columns and partition column types.
Why are the changes needed?
Explicitly throw exception for an unsupported case for clarity
Does this PR introduce any user-facing change?
No
How was this patch tested?
unit test
Was this patch authored or co-authored using generative AI tooling?
Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com