AfterShip / clickhouse-sql-parser / 28708351886

53%

master: 54%

Build Type

Pull #279

github

Committed by git-hulk

Commit Message

Fix expression precedence for lambda, ternary and NOT

The precedence table disagreed with ClickHouse in several places and two
operators were unreachable. All of these misparses round-tripped to the
same SQL text, so the golden tests never caught them:

- Lambda `->` bound tightest instead of loosest: `x -> x + 1` parsed as
  `(x -> x) + 1`. It now binds loosest and is right-associative.
- Ternary `?:` bound above OR/AND: `a OR b ? 1 : 2` parsed as
  `a OR (b ? 1 : 2)` instead of `(a OR b) ? 1 : 2`.
- Prefix NOT grabbed only a primary: `NOT a = b` parsed as `(NOT a) = b`
  instead of `NOT (a = b)`, and `NOT NOT a` misparsed the second NOT as
  a column named NOT.
- `x NOT BETWEEN 1 AND 2` was a hard error: the BETWEEN branch inside
  parseInfix's NOT case sat after the default arm and was dead code.
  BetweenClause gains a Not field.
- `NOT IN` entered through NOT's low precedence while `IN` had its own,
  so `a = b IN (1)` and `a = b NOT IN (1)` grouped differently.
- getNextPrecedence listed TokenKindDot/TokenKindDash twice.
- INTERSECT was not a keyword at all: `SELECT 1 INTERSECT SELECT 2`
  misparsed as `SELECT 1 AS INTERSECT` then errored. It is now wired
  like EXCEPT (SelectQuery.Intersect), including walk/format support;
  walk also gains the previously missing Except child.

Golden JSON diffs are purely the two new fields (BetweenClause.Not,
SelectQuery.Intersect); no format output changed. New structural tests
in precedence_test.go assert the tree shapes directly.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Pull Request Pull Request #279: Fix expression precedence for lambda, ternary and NOT operators

Coverage Stats

57 of 71 new or added lines in 5 files covered. (80.28%)

1 existing line in 1 file now uncovered.

8545 of 16159 relevant lines covered (52.88%)

3019.95 hits per line