Support FROM-less SELECT of literal expressions — SELECT 1 is the connection/health idiom of Tableau and Superset and is rejected

[fupelaqu]

Found by Epic 19 / Story 19.4 (BI-tool emitted-SQL capture): SELECT 1 without FROM is the connection/health idiom of both BI tools we captured, and the dialect rejects it — with browse-blocking consequences, not cosmetic ones.

The two captured manifestations

1. Tableau Desktop (Other Databases (JDBC), dialect MySQL): re-issues a bare SELECT 1 as a connectivity check on every user interaction. Each one fails —

   string matching regex '(?i)(FROM)\b' expected but end of source found
   

   — and the failure aborts the interaction (QueryTask ... exiting with error class java.sql.SQLException, Failed in fetchResults. SQLState=400 in jprotocolserver.log), killing the browse flow outright. Story 19.4 could only proceed by synthesizing the SELECT 1 answer in a host-side shim.

2. Apache Superset 6.0.1 (Flight SQL venue): its database connection test emits SELECT 1 (and its engine-spec probe SELECT 1 LIMIT 100); both are rejected, so the documented Settings -> Database Connections flow cannot complete against SoftClient4ES (the working demo only connects because superset import-datasources skips the live test). Captured in the 19.4 corpus (rows superset.flightsql.w1.009/w1.010, seam = sidecar gateway log).

Grammar locus

FROM is mandatory in the SELECT production; the statement parser has no FROM-less branch (the parse error above is the FROM combinator failing at end of input).

Recommendation

Support FROM-less SELECT of literal/scalar expressions (SELECT 1, SELECT 1 AS x, SELECT PI etc. — engines commonly treat it as a one-row projection). This single form unblocks the standard health-check idiom of the JDBC/SQLAlchemy ecosystem: connection pools (connectionTestQuery), SQLAlchemy pre-ping, Tableau, Superset, DBeaver all default to it.

R2a-relevant: classified absent_feature in the 19.4 unsupported corpus; it blocks tool browse flows before a single workload query runs.