Skip to content

Support typed array literals ARRAY<T>[...] - #9

Merged
moshap-firebolt merged 1 commit into
firebolt/v0.62.0-patchesfrom
bigquery-typed-array-literal
Aug 20, 2026
Merged

Support typed array literals ARRAY<T>[...]#9
moshap-firebolt merged 1 commit into
firebolt/v0.62.0-patchesfrom
bigquery-typed-array-literal

Conversation

@moshap-firebolt

@moshap-firebolt moshap-firebolt commented Aug 20, 2026

Copy link
Copy Markdown

GoogleSQL/BigQuery allows an array literal to declare its element type in angle brackets before the elements, e.g. ARRAY<INT64>[1, 2, 3] (analogous to the already-supported typed struct literal STRUCT<...>(...)). Previously this mis-parsed as ARRAY < T > [..] — an identifier, comparisons and a subscript — which surfaced downstream as Column 'array' does not exist.

Changes

  • Add an element_type: Option<DataType> field to the Array expression node (None for untyped [..] / ARRAY[..]). Display renders ARRAY<T>[...] when set, so typed literals round-trip.
  • Parse ARRAY <element_type> [ ... ] when a new supports_array_typed_literal dialect flag is set (BigQuery), reusing the data-type parser — so nested ARRAY<STRUCT<...>> / ARRAY<ARRAY<...>> element types and empty ARRAY<INT64>[] all work. Untyped arrays are unchanged.

Tests

  • tests/sqlparser_bigquery.rs::parse_typed_array_literal — round-trips scalar / empty / nested-struct / nested-array element types, and asserts the recorded element_type (and None for untyped arrays).

Note: ARRAY<ARRAY<...>> is accepted at the grammar level (valid GoogleSQL); the arrays-of-arrays restriction is a BigQuery semantic rule enforced downstream, consistent with the parser's permissive design.


Note

Cursor Bugbot is generating a summary for commit b346f24. Configure here.

GoogleSQL/BigQuery allows an array literal to declare its element type in angle
brackets before the elements, e.g. `ARRAY<INT64>[1, 2, 3]` (analogous to the
already-supported typed struct literal `STRUCT<...>(...)`). Previously this
mis-parsed as `ARRAY < T > [..]` (an identifier, comparisons and a subscript).

- Add an `element_type: Option<DataType>` field to the `Array` expression node,
  `None` for untyped `[..]` / `ARRAY[..]`. `Display` renders `ARRAY<T>[...]`
  when set.
- Parse `ARRAY <element_type> [ ... ]` when a new `supports_array_typed_literal`
  dialect flag is set (BigQuery), reusing the data-type parser (so nested
  `ARRAY<STRUCT<...>>` / `ARRAY<ARRAY<...>>` element types and empty
  `ARRAY<INT64>[]` all work). Untyped arrays are unchanged.
- Test `parse_typed_array_literal` in `tests/sqlparser_bigquery.rs` covers the
  round-trip and the recorded element type.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
@moshap-firebolt
moshap-firebolt merged commit b82e0d9 into firebolt/v0.62.0-patches Aug 20, 2026
21 checks passed

@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 b346f24. Configure here.

Comment thread src/parser/mod.rs
{
self.expect_token(&Token::Lt)?;
let (element_type, trailing_bracket) = self.parse_data_type_helper()?;
self.expect_closing_angle_bracket(trailing_bracket)?;

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Unmatched angle bracket is swallowed

Low Severity

The typed array path calls expect_closing_angle_bracket and drops its return value. When that helper consumes >>, the leftover > is never reported, so an extra closing bracket is accepted and the literal still parses. Typed STRUCT literals check this leftover flag and error instead.

Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit b346f24. Configure here.

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