lhadhazy opened a new pull request, #2596:
URL: https://github.com/apache/datafusion-sqlparser-rs/pull/2596
Fixes #2462. Thanks @zvonimir-dd for the analysis in the issue — this
follows the approach you set out there.
`->` and `->>` carry `Precedence::PgOther` (21), which sits below `*` (40),
`+` (30) and the bitwise operators, so the arrows under-bind on both sides:
| SQL | Before | After / MySQL |
|---|---|---|
| `c -> '$.a' + 1` | `c -> ('$.a' + 1)` | `(c -> '$.a') + 1` |
| `c ->> '$.a' * 2` | `c ->> ('$.a' * 2)` | `(c ->> '$.a') * 2` |
| `1 + c -> '$.a'` | `(1 + c) -> '$.a'` | `1 + (c -> '$.a')` |
| `c -> '$.a' & 1` | `c -> ('$.a' & 1)` | `(c -> '$.a') & 1` |
`c -> path` is defined as `JSON_EXTRACT(c, path)`
([docs](https://dev.mysql.com/doc/refman/8.4/en/json-search-functions.html)),
so the extraction has to happen before any operator can use its result. `c ->
('$.a' + 1)` adds a number to a JSON path.
This takes the first of the two approaches in the issue, since `PgOther` =
21 is correct for PostgreSQL and a shared row cannot be right for both engines.
The arrows move to their own `Precedence::JsonExtraction`, which takes the same
value as `PgOther` in the shared table — so no dialect changes by default, and
the rest of that operator family stays put — and `MySqlDialect` prices those
two tokens above `MulDivModOp` through `get_next_precedence`, without
duplicating the table.
On the issue's two open questions:
**`GenericDialect` follows MySQL.** The contributing guide asks that a
dialect-specific feature parse under both the relevant dialect and Generic, and
Generic already gives MySQL's grouping for every other operator in these
expressions.
**Height: 42**, just above `MulDivModOp` (40) and `AtTz` (41), below
`DoubleColon` (50). Anything above `MulDivModOp` is correct for valid input,
since the right operand is lexically a path string. Happy to move it nearer
`DoubleColon` if you prefer the more literal reading of the grammar.
I checked which dialects this actually moves, by parsing `SELECT c -> 'p' +
1` under each: MySQL and Generic group it the new way; PostgreSQL, SQLite,
Hive, BigQuery, Redshift and MsSQL are untouched; ClickHouse, Snowflake,
Databricks and DuckDB read `->` as a lambda, where precedence never applies.
The issue's table stops at arithmetic while its title does not — `&` and `^`
misgrouped for the same reason, at 23 and 22. `|` was already correct, but only
because `Pipe` shares 21 with `PgOther` and left associativity gives the same
answer, so the test pins it against a future change to either value.
Tests in `parse_json_arrow_arithmetic_precedence`, beside
`parse_div_precedence` and `parse_is_distinct_from_json_arrow_precedence`,
running under both dialects. `cargo test --locked --all-features`, `cargo fmt
--check` and `cargo clippy --locked --all-targets --all-features -- -D
warnings` all pass.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
