Accept the BI dialect spellings — CHAR_LENGTH, TIMESTAMPADD, TOP n (72/99) (+ a watcher operator-ordering fix)

[fupelaqu]

Closes #361
Closes #362

Four dialect spellings a BI tool emits that the grammar rejected, each sourced from a residual row of the Epic 19 capture with a bisected cause — plus one unrelated defect found while sizing them.

What is accepted now

spelling	becomes	corpus row
CHAR_LENGTH / CHARACTER_LENGTH	LENGTH	tableau.sql92.w8.032
TIMESTAMPADD(unit, n, base)	DATETIME_ADD	tableau.sql92.w4.025 (partly — see below)
TIMESTAMPDIFF(unit, d1, d2)	DATE_DIFF	—
SQL_TSI_DAY, SQL_TSI_MONTH, …	the units we already have	—
SELECT TOP n, SELECT TOP (n)	LIMIT n	tableau.sql92.wx.010

Every one is an alias or a re-spelling, never a second mechanism: the render normalises to the canonical form, and that render re-parses. The ODBC (unit, count, base) order TIMESTAMPADD uses is the transactSql form this parser has always accepted, so the alias adds a name and no semantics.

Two things deliberately not done:

• TIMESTAMPSUB is not added. It exists in neither ODBC nor MySQL (verified against the 8.4 reference), and the capture itself uses a negative count with TIMESTAMPADD — which already worked.
• tableau.sql92.w4.025 does not flip. It had two independent blockers; this PR removes the function-spelling one. The other is the ODBC {fn … } escape, which is a different mechanism (a pre-parse normalisation, not a grammar production) and belongs in its own PR.

Also fixed: CREATE WATCHER … WHEN x >= 0

Parser.comparison_operator ordered gt before ge and lt before le. These are string literals, not anchored tokens, so > matched the first character of >= and left = for the value production:

WHEN … >  0   OK        WHEN … >= 0   REJECTED
WHEN … <  0   OK        WHEN … <= 0   REJECTED
WHEN … =  0   OK        WHEN … <> 0   OK

WhereParser.comparisonOp always had the right order; this production did not. Unrelated to the BI work — found while sizing the <= / <=> prefix hazard for a future <=> change.

🔴 Two defects an independent review caught before this was pushed

1. SELECT top -1 AS x FROM t regressed from parsing to a hard error. A named "non-negative row count" refusal used err, and Parsers.| never tries another alternative after an Error — so opt could not backtrack to reading top as a column. It reached every SELECT-bearing production (CTAS, derived tables, IN subqueries). The guard is now a failure, and each case is pinned against the same statement with a different identifier as the control. The spec had pinned the defect; that test is deleted, not adjusted.
2. SELECT TOP 5 PERCENT a FROM t parsed, as the column PERCENT aliased to a. A loud rejection had become a silent wrong answer (GROUP BY without LIMIT silently returns only the top 10 groups (silent wrong answer) #205/GROUP BY without an aggregate in the SELECT list returns per-document rows instead of one row per group (silent wrong answer) #253 family). TOP n PERCENT and TOP n WITH TIES are now refused by name.

Also from the review: an Int overflow that defeated the count guard one line after it was written (TOP 2147483648 → LIMIT -2147483648), and a TIMESTAMPDIFF assertion satisfied by the sign-inverted render — the very binding it existed to pin.

Known gap, deliberately not closed: SELECT DISTINCT TOP n is rejected while the invalid SELECT TOP n DISTINCT is accepted, because DISTINCT binds to the identifier, not to the SELECT. Closing it means giving DISTINCT two owners, which is a restructuring, not a fix.

Scoreboard — 70/99 → 72/99 · 72/75

Two rows flip rejected → parses, so PARSE moves 91 → 93, and both are scored:

capture id	was	now
tableau.sql92.w8.032 (SUM(CHAR_LENGTH(name)))	rejected · local:char-length-spelling	parses · issue:361 · fixed
tableau.sql92.wx.010 (SELECT TOP 1 *)	rejected · local:select-top-n	parses · issue:361 · fixed

scored = fixed requires a merged suite asserting the statement's correctness, not its parse — so the second commit supplies one. The never-counted gap returns to "21 capability probes + 0 that parse but answer wrongly, incompletely or UNMEASURED".

The exception is a second compiled singleton (Issue361FixedIds) beside Issue328FixedIds — never a widened owner.startsWith("issue:") predicate, which would hand fixed the meaning "it parsed" to every future issue owner in silence. Checked in both directions, so an id the code excepts that the table stops scoring is a loud dead exception.

tableau.sql92.w4.025 deliberately stays rejected and keeps its local owner: its TIMESTAMPADD blocker is gone, its {fn …} escape blocker is not.

The execution suite, and why it cannot be passed by accepting a spelling

BiDialectExecutionSpec — testkit + 5 client subclasses, against real Elasticsearch:

• CHAR_LENGTH is asserted against a multi-byte string. 海豚 is 2 characters and 6 UTF-8 bytes, so a byte-counting implementation — exactly what MySQL's own LENGTH does — answers 6 and reddens. An ASCII-only assertion would have been satisfied by either.
• TOP n is asserted on row count and row set against the LIMIT n spelling, over a 3-shard index of 24 documents — above Elasticsearch's default page of 10, so a dropped bound cannot hide behind the default. A control asserts the unbounded statement returns all 24.

🔴 The integration mutation was run, not assumed: removing the fold of TOP into the statement's LIMIT, while leaving TOP parsing, reddens exactly the three TOP execution rows and leaves the CHAR_LENGTH rows green.

Two defects in the suite's own first draft, both found by running it: script_fields values come back wrapped in Elasticsearch's per-field array on the row path while the same expression under an aggregation is a scalar (pre-existing, documented against #209); and the 24 bulk documents were seeded with a name that collided with one of the named rows, so 25 documents matched and every count oracle was quietly off by one.

⚠️ The new series row's commit is the literal PENDING, to be stamped at merge — better than a SHA that is wrong the moment the branch is amended. (The existing post-epic22 head row carries its parent commit, 7187c7d9; pre-existing, not touched here.)

No behaviour change on anything that parsed before

GrammarDiffProbe, 16,438 inputs, this branch vs a parser built from origin/main:

• 11 widened (reject → accept) — exactly the new spellings
• 0 narrowed
• 0 renders changed on an already-accepted input
• 59 rejected both ways with a different message (truncated inputs whose last-failing alternative shifted; several are now better)

🔴 That probe reported 0 narrowings on the defective code too — its corpus never contained SELECT top -1. It is necessary and not sufficient; the review's hand-built input is what found the regression.

Parse cost

Interleaved control/branch, 5 rounds each, first round of each side discarded (medians, µs):

	control	branch
bare SELECT	94.3 [91.8, 113.5]	98.2 [96.4, 144.7]
SELECT list + LIMIT	304.5 [289.0, 478.4]	300.9 [286.2, 476.4]
sum of medians	4215 [4149, 4331]	4205 [4026, 4396]

All three ranges overlap ⇒ no signal. Reported as no signal rather than a direction, though top.? does add one optional regex attempt per SELECT.

Mutation matrix

Every mechanism checked by the smallest edit that disables that decision alone — never a whole-branch revert:

mutation	tests red
remove the CHAR_LENGTH aliases	2
remove TIMESTAMPADD	3
remove SQL_TSI_DAY only	2
keep TOP parsing, drop the LIMIT fold	2
drop the TOP+LIMIT conflict error	1
drop the count guard	1
restore the old watcher operator order	1
make top required (kill opt backtracking)	12

Verification

• sql/test 1348 passed · core/test 1129 passed
• BiDialectExecutionSpec 8/8 on each of the five clients — real ES 6.8 (rest + jest), 7.17, 8.18, 9.0
• Scala 2.12.20: sql/compile, sql/Test/compile, core/compile, core/Test/compile all clean
• CI lint line verbatim: headerCheck scalafmtSbtCheck scalafmtCheck test:scalafmtCheck
• The rest of the ES integration matrix is unchanged by this branch and was not re-run.

🤖 Generated with Claude Code