kokhlo commented on issue #38453: URL: https://github.com/apache/superset/issues/38453#issuecomment-6102982564
Root cause found — it is not DuckDB adding the escape, it is SQLAlchemy's dialect default leaking through. duckdb-engine subclasses the psycopg2 PostgreSQL dialect, whose class-level `_backslash_escapes` default is `True`. PostgreSQL corrects this per-connection by probing `standard_conforming_strings` (`_set_backslash_escapes`), but DuckDB has no such knob and never runs that probe, so the flag stays `True` forever. Superset compiles filter values with `literal_binds` (`Database.compile_sqla_query`), so `name\email` renders as `'name\\email'` — which real DuckDB reads as a literal two-backslash string that matches nothing. Verified on the pinned versions (sqlalchemy 2.0.52, duckdb-engine 0.17.0, live in-process DuckDB): `SELECT 'name\\email' = 'name\email'` → False. Fix in #45180: `DuckDBEngineSpec.register_engine_events` sets `engine.dialect._backslash_escapes = False` — the same correction `_normalize_postgresql_backslash_escapes` already applies for PostgreSQL on the Jinja path, but the main compile path had no equivalent for duckdb. Regression tests included (one unit, one end-to-end against live DuckDB). -- 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]
