Repository navigation
Parse TRUNC/TRUNCATE's bare second argument as a column - #104
Merged
Merged
Conversation
A bare identifier as TRUNC's second argument is a date part in Snowflake only when no column of that name is in scope: TRUNC(1, DAY) compiled with no table (receipt sf.functions.trunc2.ka4427f986c78), while TRUNC(x, s) with a column s truncated numerically (C's slice 1 cases trunc.trunc/trunc.truncate t001, t005, t006, t007). The parser cannot see scope, so it keeps the identifier as a column, as polyglot does, instead of rewriting date-part spellings to a date part.
Only change: sf.functions.trunc2 verified -> unverified, because its auditor review fingerprints the old tree of SELECT TRUNC ( 1 , DAY ). Satisfied obligations 68,585, parsed/refused cases and the 5,128 known parser/receipt disagreements are unchanged; no receipt verdict moves. The auditor renews the review under D118.
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.
Unblocks C's slice 1 (land/d151-s1). Coordinator priority: this lands before the slice. It touches crates/sqlquack-syntax, so it goes on the auditor's D118 re-read list.
Bug. SQLQuack rewrote TRUNC/TRUNCATE's bare second argument into a date part (
{"var": …}) whenever its spelling named a date part.TRUNC(x, s)with a NUMBER columnsbecame "second". Snowflake recorded numeric truncation for those cases, and Polyglot parsessas a column. This was the only Rust failure slice 1 causes (runs::test_exact, 8 differences in trunc.trunc / trunc.truncate t001_int, t005_null_x, t006_null_scale, t007_scale_past). It was also the cause of trunc.truncate's SQ0002node:varrefusal.Fix. The parser keeps the identifier as a column, as Polyglot does. Snowflake decides by scope, which the parser can't see:
SELECT TRUNC ( 1 , DAY )compiled with no table in scope (receipt sf.functions.trunc2.ka4427f986c78, accept, stage semantic).TRUNC(x, s)with a columnstruncated numerically.This reverses the TRUNC part of d704778, an auditor tree finding. DATEDIFF, TIMEDIFF, TIMESTAMPDIFF, EXTRACT and DATE_TRUNC keep their date-part rewrite. The test_fixes pins now assert a column for
TRUNC(x, DAY)andTRUNCATE(x, s).Zero-fire evidence
sqlquack checkstill reports no problems for it.snapshoton the committed tree: the only change is sf.functions.trunc2 verified → unverified, because its auditor review fingerprints the old tree. Satisfied obligations (68,585), parsed and refused cases, and the 5,128 known receipt disagreements are identical. The auditor renews trunc2 under D118: 2,388 → 2,387 verified until then.sqlquack check: no problems forTRUNC(1, DAY),TRUNC(x, s) FROM torTRUNC(d, day) FROM t.The converter is unchanged. A bare TRUNC unit was already refused (
node:var), and a TRUNC scale from a column stays refused ("places other than a literal integer"). ResolvingTRUNC(d, day)by type is a possible follow-up, which needs a receipt.