bug(trino): SQL formatter rewrites Trino-native functions to invalid names (date_diff→datediff, to_hex→hex) via sqlglot dialect mismatch #39100
Description
Bug description
When "Format SQL" is enabled in SQL Lab, Superset passes Trino queries through
sqlglot for pretty-printing but does not thread the Trino dialect through to
sqlglot's generator. This causes sqlglot to fall back to its generic SQL
generator, which renames several Trino-native functions to names that Trino
does not recognise:
date_diff → datediff (FUNCTION_NOT_FOUND)
to_hex → hex (FUNCTION_NOT_FOUND)
from_hex → unhex (FUNCTION_NOT_FOUND)
date_trunc → (argument order swapped in some paths)
The error from Trino is always the same pattern:
TrinoUserError(type=USER_ERROR, name=FUNCTION_NOT_FOUND,
message="line N:N: Function 'datediff' not registered")
sqlglot itself is NOT at fault. When the dialect is passed correctly, it
round-trips Trino functions perfectly:
sqlglot.transpile("SELECT date_diff('day', a, b)", read="trino", write="trino")
→ ["SELECT date_diff('day', a, b)"] ✅
sqlglot.transpile("SELECT date_diff('day', a, b)") # no dialect
→ ["SELECT DATEDIFF(b, a)"] ❌ ← what Superset produces
Root cause: Superset's SQL formatting path calls sqlglot without specifying
the write dialect for TrinoEngineSpec, so the generic generator is used.
The fix belongs in superset/db_engine_specs/presto.py (PrestoBaseEngineSpec)
or trino.py, adding explicit sqlglot TRANSFORMS overrides for the affected
exp.* AST nodes so they emit the correct Trino function names regardless of
how the generator is invoked.
Screenshots/recordings
- Connect Superset 6.0.0 (or 6.1rc1) to a Trino database (any version)
- Open SQL Lab, ensure "Format SQL" is ON
- Run:
SELECT date_diff('day', DATE '2023-01-01', current_date) - Observe error:
TrinoUserError: Function 'datediff' not registered - Disable "Format SQL" — same query runs successfully
- Same issue reproducible with: to_hex(), from_hex(), sha256(), md5()
Superset version
master / latest-dev
Python version
3.9
Node version
16
Browser
Chrome
Additional context
Expected result:
Trino-native functions (date_diff, to_hex, from_hex, md5, sha256, date_add)
are passed through to Trino unchanged, regardless of whether "Format SQL"
is enabled.
Checklist
- I have searched Superset docs and Slack and didn't find a solution to my problem.
- I have searched the GitHub issue tracker and didn't find a similar bug report.
- I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.
Activity
dosubot commentedon Apr 3, 2026
Good find — and you're right that sqlglot itself handles Trino functions correctly when the dialect is specified. The root cause is actually in the frontend, not the engine specs or the backend formatting code.
The backend formatting path in
superset/sql/parse.pydoes accept and correctly use the Trino dialect when provided — both forsqlglot.parse(dialect=...)andDialect.generate(...). Trino is properly mapped toDialects.TRINOin theSQLGLOT_DIALECTSdictionary [1].The problem is that SQL Lab's frontend never passes the
engineparameter when calling the format endpoint. Insuperset-frontend/src/SqlLab/actions/sqlLab.js, theformatQueryfunction sends only{ sql }— there's even a TODO comment acknowledging this:Without the
engineparameter, the backend has no dialect to pass to sqlglot, so sqlglot falls back to its generic SQL generator — which is exactly what producesdatediff,hex,unhex, etc.Interestingly, the
ViewQuerycomponent in the Explore view does pass the engine parameter correctly by reading it from dataset metadata.So the fix would be to pass the database engine (e.g.,
"trino") from the SQL Lab editor to the/api/v1/sqllab/format_sql/endpoint, similar to howViewQuery.tsxalready does it. The SQL Lab editor has access to the selected database — it just needs to include its backend in the format request payload.To reply, just mention @dosu.
Docs are dead. Just use Dosu.
shimonp commentedon Apr 4, 2026
I am new to the bug fixing process in Superset. Am I expected to provide the fix you have described or the core team will review, implement the fix and merge into main branch on its own? It does not work in v6.0.0 or 6.1rc1 and I hope that 6.1 won't be released without implementing and testing this trivial fix. We use Trino engine extensively, so custom syntax of Trino sql dialect is important to us. Best regards.
rusackas commentedon Apr 15, 2026
@shimonp if you think the bot is right, and you're willing to test it locally, opening a PR would be much appreciated. If you do, we'll try to review it and merge it, but testing it is tricker since not all of use use Trino, so your validation would be appreciated.
Tagging @betodealmeida for context here, in case they have input.
shimonp commentedon Apr 15, 2026
justinpark commentedon Apr 15, 2026
@shimonp instead of the ai suggestion, I made the hotfix by using the database_id (which recently added by #36277)
shimonp commentedon Apr 15, 2026
I agree with this fix. Let me know if you need help to test the fix.