fix(parser)!: move JSON extraction operators to Postgres's binary-operator precedence tier

[fivetran-kwoodbeck]

Fixes #8035 where ->, ->>, #>, #>>, and ? were parsed as tight-binding column accessors (like . and ::) via COLUMN_OPERATORS, instead of Postgres's actual "any other operator" precedence tier, below +/-, level with || and the bitwise operators, left-associative.

This caused casts, subscripts, and arithmetic adjacent to these operators to bind to the wrong operand. To fix it:

• Added JSON_EXTRACT_OPERATORS, a new operator tier parsed inside _parse_bitwise in parser.py, alongside the existing || handling.
• Moved the relevant operators out of COLUMN_OPERATORS and into JSON_EXTRACT_OPERATORS for PostgresParser and DuckDBParser. Other dialects still treat -> as lambda syntax.

Sample input:

SELECT a #>> b::TEXT[]

Previous: cast attaches to the whole extract:

SELECT CAST(a #>> b AS TEXT[])

Fixed: cast attaches to the path operand, matching Postgres:

SELECT a #>> CAST(b AS TEXT[])

[georgesittas]

There are some operators that also aren't parsed correctly in main today: ?&, ?|, @>, <@ and &&. The problem is that they're in RANGE_PARSERS, i.e., in the "comparison tier". We can fix them as a follow-up.

SELECT '{"a":[1,2]}'::jsonb @> '{"a":[1]}'::jsonb -> 'a';
SELECT '{"a":[1]}'::jsonb <@ '{"a":[1,2]}'::jsonb -> 'a';
SELECT '{"a":1}'::jsonb ?& ARRAY['a'] -> 'b';
SELECT '{"a":1}'::jsonb ?| ARRAY['a'] -> 'b';
SELECT ARRAY[1] && ARRAY[1] -> 'a';

-- ERROR: operator does not exist: boolean -> unknown

[georgesittas]

Not sure if this is a good name, e.g., Postgres adds JSONBContains in it which isn't an "extraction. What about BITWISE_OPERATORS?

[fivetran-kwoodbeck]

I'm not sure about BITWISE_OPERATORS, they don't have AND/OR/XOR/shift semantics. How about just JSON_OPERATORS?

[georgesittas]

Go for it.

[georgesittas]

These lambdas and 3 lambdas in the Postgres parser are identical to the base ones. Should we clean these up?

[fivetran-kwoodbeck]

There are some operators that also aren't parsed correctly in main today: ?&, ?|, @>, <@ and &&. The problem is that they're in RANGE_PARSERS, i.e., in the "comparison tier". We can fix them as a follow-up.

SELECT '{"a":[1,2]}'::jsonb @> '{"a":[1]}'::jsonb -> 'a';
SELECT '{"a":[1]}'::jsonb <@ '{"a":[1,2]}'::jsonb -> 'a';
SELECT '{"a":1}'::jsonb ?& ARRAY['a'] -> 'b';
SELECT '{"a":1}'::jsonb ?| ARRAY['a'] -> 'b';
SELECT ARRAY[1] && ARRAY[1] -> 'a';

-- ERROR: operator does not exist: boolean -> unknown

I'll add it as a ticket, I may have found another duckdb operator precedence issue too.

[github-actions]

SQLGlot Integration Test Results

✅ All tests passed

Comparing:

• this branch (sqlglot:parser/fix-json-arrow-operator-precedence @ sqlglot 9fbac96)
• baseline (main @ sqlglot a9c0bea)

Overall

main: 182937 total, 160861 passed (pass rate: 87.9%)

sqlglot:parser/fix-json-arrow-operator-precedence: 176566 total, 155532 passed (pass rate: 88.1%)

Transitions:
No change

Dialect pair changes: 0 previous results not found, 2 current results not found

✅ All tests passed