Metadata queries break on catalog, schema or table names containing a quote or backslash

Abierto
#1,747 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 6 días

@MsMansiDhruv ya está trabajando en esto.

Desde el 29/10/2026.

  • #1758 de @MsMansiDhruv — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python, sql

Línea de trabajo

Start with the listed macros in relations/tags.sql, relations/components/, adapters/catalog.sql, adapters/metadata.sql, and materializations/clone/strategies.sql; compare their string literal handling with relations/components/comment.sql. Also inspect show_table_extended_sql and check_schema_exists_sql for the related LIKE pattern issue. Add unit cases for names containing both a quote and a backslash, and confirm the generated SQL escapes both correctly across the affected macros.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug
Describe the bug

Several metadata macros paste relation names straight into SQL string literals without escaping them. Unity Catalog allows a ' or \ in a catalog, schema or table name when the name is backtick-quoted, for example `orders'eu`. For such a relation, the generated query is invalid:

... WHERE table_catalog = 'main' AND table_schema = 'prod' AND table_name = 'orders'eu'

The query fails to parse, so the materialization or command that issued it fails before running any DDL. Identifier quoting in these macros is fine; only the string literals are affected.

Affected macros (all build = '{{ relation.<part>|lower }}' predicates):

  • relations/tags.sql: fetch_tags_sql
  • relations/components/row_filter.sql: fetch_row_filters_sql
  • relations/components/column_mask.sql: fetch_column_masks_sql
  • relations/components/column_tags.sql: fetch_column_tags_sql
  • relations/components/constraints.sql: fetch_non_null_constraint_columns_sql, fetch_primary_key_constraints_sql, fetch_foreign_key_constraints_sql
  • adapters/catalog.sql: databricks__get_catalog_schemas_where_clause_sql, databricks__get_catalog_relations_where_clause_sql
  • adapters/metadata.sql: get_relation_last_modified_sql, get_view_description_sql, get_uc_tables_sql
  • materializations/clone/strategies.sql: clone_source_policies_sql, added in #1745, which runs on every dbt clone of a Unity Catalog table.

Related, but a different quoting problem: show_table_extended_sql and check_schema_exists_sql build LIKE '<name>' patterns from relation names. Those need both literal escaping and LIKE-pattern handling.

Steps To Reproduce
CREATE SCHEMA main.quote_probe;
CREATE TABLE main.quote_probe.`orders'eu` (id INT);

-- What fetch_row_filters_sql / clone_source_policies_sql generate today: fails to parse
SELECT 1 FROM main.information_schema.row_filters
WHERE table_catalog = 'main' AND table_schema = 'quote_probe' AND table_name = 'orders'eu';

-- Escaped: runs, and finds the filter once one is set
SELECT 1 FROM main.information_schema.row_filters
WHERE table_catalog = 'main' AND table_schema = 'quote_probe' AND table_name = 'orders\'eu';

In dbt, a model with alias: "orders'eu" hits this as soon as one of the macros above runs for it. Examples:

  • dbt clone once #1745 lands.
  • Tag or constraint diffs on a later dbt run.
  • dbt docs generate, which goes through the catalog macros.
Expected behavior

Every relation-name string literal in generated SQL is escaped, \ first and then ', the way relations/components/comment.sql already escapes comments: | replace("\\", "\\\\") | replace("'", "\\'"). A shared helper macro would keep the call sites consistent. Each fixed *_sql macro gets a unit case with a name containing ' and \.

System information

Reproduced on a Unity Catalog SQL warehouse against the 1.13.latest branch. The pattern is the same on main.

Additional context

Found while reviewing #1745. We agreed to fix all call sites together on the next .latest branch rather than in that PR.

Lenguaje dominante
Python
Estrellas
391
Forks
231
Merge medio
9 d 7 h
PR fusionados (30 d)
29

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de databricks/dbt-databricks

Todos los issues de databricks/dbt-databricks

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.