Repository navigation
Conversation
A rebuild with the case builder settles ten cases whose receipts landed without a rebuild: six observed cases take the expect their receipts agree on (three reject, three accept with a semantic stage), and four accepted cases gain the semantic stage their receipts record. No case is added or removed and no SQL, setup or session changes.
The source list stops before a name followed by =, taking it for the first copy option, so COPY INTO <location> FROM v1 = ( ) parsed with no source and read v1 = ( ) as an option. Snowflake rejects it as a syntax error (1003). An empty source after FROM or TO is now a parse error; COPY INTO <table> with no FROM still parses.
The page's examples partition by a parenthesized expression, such as
PARTITION BY ('date=' || ...), and follow it with HEADER = TRUE, but no case covered either
shape. Three observed positives (o540-o542) ask Snowflake for its verdict.
Six recorded syntax errors write an external location's STORAGE_INTEGRATION or CREDENTIALS
and ENCRYPTION after FROM, then PARTITION BY, but no receipt says which part Snowflake
refuses. Five observed positives (o543-o547) separate the location parameters' position
from PARTITION BY.
cpby-ex-00, the eight copy-into-location cases built at f37efb5. Two are syntax errors (1003/42000): PARTITION BY after STORAGE_INTEGRATION, and STORAGE_INTEGRATION before FROM. The other six fail after parsing (2003 on the missing table, 90105 with no current database). Inventory equal, no changes, 0.105 credits.
Import 172 answers the eight observed COPY INTO <location> cases: six parse and fail later (2003 or 90105), so they settle as accept with a semantic stage; PARTITION BY after STORAGE_INTEGRATION and STORAGE_INTEGRATION before FROM are syntax errors (1003), so those two settle as reject.
…lake does - PARTITION BY takes a full expression, so ( 'date=' || v1 ) and a following HEADER = TRUE parse; before, the option reader took BY as PARTITION's value. - In Snowflake's faithful modes, anything but FROM right after the location, and PARTITION BY after STORAGE_INTEGRATION, CREDENTIALS or ENCRYPTION, are syntax errors with a hint, as import 172 records (1003 at STORAGE_INTEGRATION and at BY). - A stage reference no longer takes FROM as its name (@~, @, @%) and reads a table stage after a namespace (@v1.%v1); those parsed before only because FROM was then read as an option.
kvlonge
added a commit
that referenced
this pull request
Nov 7, 2026
… options after @~ Only PARTITION BY after STORAGE_INTEGRATION has a receipt. Four observed cases ask Snowflake for the rest: PARTITION BY after an Azure location's CREDENTIALS and after an S3 location's ENCRYPTION, PARTITION BY on COPY INTO a table, and FILES after a user stage source.
…re stage - COPY INTO a table has no PARTITION BY. Reading it as an expression accepted COPY INTO t1 FROM @s1 PARTITION BY 1, which failed to parse before; in Snowflake's faithful modes it is now a syntax error with a hint. - A bare @~, @ or @% no longer takes an option name such as FILES or PATTERN as its own name, so COPY INTO t1 FROM @~ FILES = ( 'a' ) parses.
The ENCRYPTION case also wrote STORAGE_INTEGRATION, whose receipt already decides it, so its receipt could not say whether ENCRYPTION alone puts PARTITION BY out of place.
…table, 3 receipts cp145-ex-00, three of the four cases built at e99c160. All three are syntax errors at BY (1003/42000): PARTITION BY after CREDENTIALS, after ENCRYPTION alone, and on COPY INTO a table. The fourth (FILES after @~) was held by the guard because it touches the connecting user's stage, and was not run. Inventory equal, no changes, 0.0 credits.
…ess stages Import 173 records 1003 at BY for PARTITION BY after an Azure location's CREDENTIALS (o548), after an S3 location's ENCRYPTION alone (o549) and on COPY INTO a table (o726), so all three settle as reject. The @~ FILES case (o727) stays observed: the receipt guard holds the connecting user's stage offline. Two observed positives ask the same question of the nameless stages @ and @% (o728, o729).
kvlonge
added a commit
that referenced
this pull request
Nov 7, 2026
…ipts cp145b-ex-00, the two cases built at b19fdea. COPY INTO t1 FROM @ and FROM @%, each with FILES = ( 'a' ), fail after parsing on the missing table (1757/42601). Inventory equal, no changes, 0.219 credits.
Snowflake parses COPY INTO t1 FROM @ FILES = ( 'a' ) and @% FILES = ( 'a' ) and fails them after parsing (1757), so o728 and o729 settle as accept with a semantic stage.
The empty-source check ran in every dialect and mode, so PostgreSQL COPY statements that polyglot also refuses failed with a different message in the exact check. It now applies only where Snowflake's statement-context rules do, as the other Snowflake refusals.
Contributor
Author
|
Closing: SQLQuack lands through local-gate trains, not PR merges (D94), so open PRs only add clutter (D628/D630). The branch is kept. Any work here that isn't on main yet is tracked by the train owner and lands through a train. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #144 (its two commits come first), so it lands after #142, #143 and #144. This is the auditor's #144 finding: PARTITION BY with a parenthesized expression, and PARTITION BY followed by HEADER, failed to parse.
Commits after #144:
sf.dml.copy-into-locationpositives (o540–o547): three PARTITION BY shapes from the page's examples, and five that separate an external location's parameters from PARTITION BY.… FROM t1 STORAGE_INTEGRATION = i1 PARTITION BY 1at BY, and… STORAGE_INTEGRATION = i1 FROM t1 …at STORAGE_INTEGRATION. Those become reject.@~,@,@%), and it reads a table stage after a namespace (@v1.%v1). Five recorded cases parsed before only because FROM was then read as an option; they still parse.Audit follow-up (4381cbb, e370a79):
COPY INTO t1 FROM @s1 PARTITION BY 1is refused again (SQ0001 with a hint, faithful modes), as before 9bad3d7.@~,@or@%no longer takes an option name such as FILES or PATTERN as its own name, soCOPY INTO t1 FROM @~ FILES = ( 'a' )parses. This gap predates the PR.@~(copy-into-table). The diff is unchanged: 45 gained, 0 lost, 5,096 contradicted.Tests: ten acceptance rows in
test_snowflake_recorded.rs, which fail without the parser change.syntax-coverage diff coverage/syntax/baseline.jsonat 9bad3d7 (parser tree 470c9ade):staleis empty.Checks: sqlquack-syntax and sqlquack-syntax-coverage tests, clippy -D warnings, fmt, fensu (scripting.rs at 1,995 lines) and the hygiene scan. The full gate runs at the slot.