EnxDev commented on code in PR #45180:
URL: https://github.com/apache/superset/pull/45180#discussion_r4256174009
##########
superset/db_engine_specs/duckdb.py:
##########
@@ -327,6 +327,18 @@ def convert_dttm(
return f"""'{dttm.isoformat(sep=" ", timespec="microseconds")}'"""
return None
+ @classmethod
+ def register_engine_events(cls, engine: sa.Engine) -> None:
+ # duckdb-engine subclasses the psycopg2 PostgreSQL dialect, whose
+ # class-level _backslash_escapes default is True. Unlike PostgreSQL,
+ # DuckDB never runs the _set_backslash_escapes probe (there is no
+ # standard_conforming_strings knob), so every literal compiled with
+ # literal_binds doubles its backslashes: a filter value like
+ # name\email is rendered as 'name\\email', which DuckDB reads as a
+ # literal double backslash and the query silently matches zero rows.
+ # DuckDB has no escape character at all, so the flag is simply wrong.
+ engine.dialect._backslash_escapes = False
Review Comment:
CodeAnt's note on this line is real. The Jinja helpers don't use this
engine: `where_in` and the value escaping in `jinja_context.py` compile against
`Database.get_dialect()`, a fresh dialect instance where the flag is back to
`True`, and `_normalize_postgresql_backslash_escapes` only corrects
`dialect.name == "postgresql"`.
So a DuckDB virtual dataset using `where_in` with a backslash value still
matches nothing. Extending that normaliser to DuckDB would close it, here or in
a follow-up.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
