The Epic 19 BI capture recorded four statements rejected for a dialect spelling, not for a missing capability. Each was bisected to a single cause; the engine already implements the semantics under a different name.
| capture id |
statement (excerpt) |
bisected cause |
tableau.sql92.w8.032 |
SUM(CHAR_LENGTH("bi_events"."name")) |
CHAR_LENGTH/CHARACTER_LENGTH are not accepted spellings (LENGTH and LEN are); every other clause parses |
tableau.sql92.wx.010 |
SELECT TOP 1 * FROM "elastic"."bi_events" |
the T-SQL TOP n clause is not in the grammar — the same statement with LIMIT 1 parses |
tableau.sql92.w4.025 |
… >= {fn TIMESTAMPADD(SQL_TSI_DAY,-89,CURRENT_DATE)} |
two independent blockers: the ODBC {fn …} escape, and the TIMESTAMPADD spelling (rejected even unbraced with a bare DAY unit) |
Why these are cheap
DATE_ADD/DATETIME_ADD already accept the ODBC/T-SQL (unit, count, base) argument order through their transactSql form, including a negative count and CURRENT_DATE as the base — measured on origin/main:
DATE_ADD(DAY, -89, CURRENT_DATE) OK round-trip=true
TIMESTAMPADD(DAY, -89, CURRENT_DATE) REJECT
So TIMESTAMPADD is a missing name, not missing behaviour. Likewise CHAR_LENGTH: our LENGTH already counts characters, which is exactly what CHAR_LENGTH means (MySQL's own LENGTH counts bytes, so CHAR_LENGTH is the spelling that agrees with us).
Scope
CHAR_LENGTH / CHARACTER_LENGTH as spellings of LENGTHTIMESTAMPADD as a spelling of DATETIME_ADD, TIMESTAMPDIFF as one of DATE_DIFF, plus the ODBC SQL_TSI_* interval namesSELECT TOP n folded into the statement's LIMIT
Out of scope, and it means tableau.sql92.w4.025 does not flip: the ODBC {fn … } escape. That is a pre-parse normalisation rather than a grammar production and belongs in its own change. TIMESTAMPSUB is also out of scope — it exists in neither ODBC nor MySQL 8.4; the capture uses a negative count with TIMESTAMPADD.
Every spelling must be an alias, not a second mechanism: the render normalises to the canonical form and that render must re-parse.
The Epic 19 BI capture recorded four statements rejected for a dialect spelling, not for a missing capability. Each was bisected to a single cause; the engine already implements the semantics under a different name.
tableau.sql92.w8.032SUM(CHAR_LENGTH("bi_events"."name"))CHAR_LENGTH/CHARACTER_LENGTHare not accepted spellings (LENGTHandLENare); every other clause parsestableau.sql92.wx.010SELECT TOP 1 * FROM "elastic"."bi_events"TOP nclause is not in the grammar — the same statement withLIMIT 1parsestableau.sql92.w4.025… >= {fn TIMESTAMPADD(SQL_TSI_DAY,-89,CURRENT_DATE)}{fn …}escape, and theTIMESTAMPADDspelling (rejected even unbraced with a bareDAYunit)Why these are cheap
DATE_ADD/DATETIME_ADDalready accept the ODBC/T-SQL(unit, count, base)argument order through theirtransactSqlform, including a negative count andCURRENT_DATEas the base — measured onorigin/main:So
TIMESTAMPADDis a missing name, not missing behaviour. LikewiseCHAR_LENGTH: ourLENGTHalready counts characters, which is exactly whatCHAR_LENGTHmeans (MySQL's ownLENGTHcounts bytes, soCHAR_LENGTHis the spelling that agrees with us).Scope
CHAR_LENGTH/CHARACTER_LENGTHas spellings ofLENGTHTIMESTAMPADDas a spelling ofDATETIME_ADD,TIMESTAMPDIFFas one ofDATE_DIFF, plus the ODBCSQL_TSI_*interval namesSELECT TOP nfolded into the statement'sLIMITOut of scope, and it means
tableau.sql92.w4.025does not flip: the ODBC{fn … }escape. That is a pre-parse normalisation rather than a grammar production and belongs in its own change.TIMESTAMPSUBis also out of scope — it exists in neither ODBC nor MySQL 8.4; the capture uses a negative count withTIMESTAMPADD.Every spelling must be an alias, not a second mechanism: the render normalises to the canonical form and that render must re-parse.