Skip to content

Spark, Databricks: read multi-units interval literals - #17

Merged
moshap-firebolt merged 4 commits into
firebolt/v0.63.0-patchesfrom
firebolt/spark-multi-unit-interval
Oct 6, 2026
Merged

moshap-firebolt merged 4 commits into
firebolt/v0.63.0-patchesfrom
firebolt/spark-multi-unit-interval

Conversation

@moshap-firebolt

@moshap-firebolt moshap-firebolt commented Oct 5, 2026 •

Copy link
Copy Markdown

Spark's multi-units interval syntax lists several value / unit pairs, INTERVAL 10 YEAR 20 MONTH, and documents it as the same thing as the string form INTERVAL '10 YEAR 20 MONTH'. Both dialects failed on the second pair (Expected: end of statement, found: 20).

A new dialect hook, supports_interval_multi_units (on for SparkSqlDialect and DatabricksDialect), lets parse_interval keep reading value / unit pairs after the first and return them as that string form, so the AST is unchanged. Values may be numbers (with a + or - sign) or strings. The extra pairs are read speculatively (maybe_parse), so a single unit, or a unit followed by anything else (INTERVAL 3 DAY + 1, INTERVAL 1 DAY, 2), parses as before.

Tests in tests/sqlparser_spark.rs cover two and three pairs, negative and plus-signed values, a string value, an alias after the literal, and the forms that must stay unchanged. The fork's full suite, fmt and clippy are clean.


Note

Low Risk
Dialect-scoped SQL parsing change with speculative lookahead; no runtime execution or data-path impact beyond accepting additional interval syntax.

Overview
Adds dialect-gated support for Spark/Databricks multi-unit interval literals like INTERVAL 10 YEAR 20 MONTH, which previously failed after the first unit pair.

A new supports_interval_multi_units hook (enabled on Spark and Databricks) extends parse_interval to optionally consume additional value/unit pairs via speculative parsing and normalize them to the equivalent string literal (INTERVAL '10 YEAR 20 MONTH'), leaving the interval AST shape unchanged. Values can be numbers or quoted strings, with optional +/- signs. Single-unit forms and intervals followed by unrelated tokens (e.g. INTERVAL 3 DAY + 1) still parse as before.

Common parser tests assert round-trip normalization for supported dialects and parse failures when the hook is off.

Reviewed by Cursor Bugbot for commit 479e11f. Bugbot is set up for automated code reviews on this repo. Configure here.

Spark's multi-units syntax lists several value / unit pairs,
INTERVAL 10 YEAR 20 MONTH, and documents it as the same thing as the
string form INTERVAL '10 YEAR 20 MONTH'. A new dialect hook,
supports_interval_multi_units, reads the pairs into that string form;
a single unit, or a unit followed by anything else, parses as before.

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit 9428126. Configure here.

Comment thread src/parser/mod.rs
Comment thread src/dialect/mod.rs Outdated
Comment thread src/parser/mod.rs Outdated
…dialect-neutral

A value in a multi-units interval may carry a sign; only minus was read,
so INTERVAL +1 DAY +2 HOURS rolled back to a binary addition and failed.
The supports_interval_multi_units doc and the parser comment no longer
name a dialect, and the doc notes the form is not ANSI SQL.
Comment thread src/dialect/mod.rs Outdated
Comment thread tests/sqlparser_spark.rs Outdated
…thout the hook

Hook-gated syntax is tested across all dialects in sqlparser_common.rs:
the multi-units forms parse for every dialect that sets
supports_interval_multi_units, and every other dialect rejects them
while still parsing a single-unit interval.
@moshap-firebolt
moshap-firebolt merged commit bae1cb2 into firebolt/v0.63.0-patches Oct 6, 2026
21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant