[coverage] Conformance findings: METADATA-037

从 tests/ 下 coverage PR diff 中失败的测试 test_empty_string_name_argument_matches_only_the_empty_string 开始，然后跟踪它所经过的 Thrift 和 kernel/SEA 元数据路径。完成的标准是：空名称参数只匹配空字符串，NULL 仍不受约束，所有调用均无错误完成，并且零行表和列结果保留其正常 schema。

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-python. Each finding is committed as an expected-failure (xfail) test in the coverage PR — the test asserts the CORRECT (post-fix) behavior and stays red until THIS driver (databricks/databricks-sql-python) is fixed, then flips green as a tripwire.

Findings

• METADATA-037 [thrift]: Thrift forwards an empty catalog argument verbatim, so the server fails the metadata call with INVALID_PARAMETER_VALUE ('name "" is not a valid name') instead of returning a correctly-shaped 0-row result; an empty name argument is a valid filter matching only "", not an invalid argument (databricks-odbc#204).
  • failing test: test_empty_string_name_argument_matches_only_the_empty_string (see the coverage PR diff under tests/)
• METADATA-037 [sea]: The kernel/SEA backend widens every present-but-empty metadata name argument into "match all" (_none_if_blank/_catalog_or_none map "" to None): tables(schema="") returned 30 rows and tables(catalog=""), tables(table=""), columns(column="") returned rows where the contract is 0 — silently turning a narrowly-scoped lookup into a catalog-wide scan (databricks-odbc#204).
  • failing test: test_empty_string_name_argument_matches_only_the_empty_string (see the coverage PR diff under tests/)
• METADATA-037: A present-but-empty ("") metadata name argument is not treated as matching only the empty string: on the kernel/SEA backend _none_if_blank()/_catalog_or_none() map "" to None ("match all"), so tables(schema="") returns every table in the catalog (30 rows) and tables(catalog="") / tables(table="") / columns(column="") likewise return rows instead of 0 — silently widening a narrowly-scoped metadata lookup into a catalog-wide scan; on Thrift an empty catalog argument is forwarded verbatim and the server fails the call with INVALID_PARAMETER_VALUE instead of returning a correctly-shaped 0-row result (databricks-odbc#204/#209).

Reproduce & Expected

METADATA-037 — Validates that a PRESENT-BUT-EMPTY (zero-length, non-null) catalog / schema / table / column name argument to a metadata call matches ONLY the empty string — i.e.

Reproduce:

• Phase 1 (baseline) — GetTables with a NULL/unset schema argument: unconstrained, returns rows
• Phase 2 — GetTables with an EMPTY schema argument ("", not NULL): matches only "", so 0 rows
• Phase 3 — GetTables with an EMPTY catalog argument: 0 rows (must NOT widen to all catalogs)
• Phase 4 — GetTables with an EMPTY table argument: 0 rows (must NOT drop the table filter)
• Phase 5 (baseline) — GetColumns with a NULL/unset column argument: returns the table's columns
• Phase 6 — GetColumns with an EMPTY column argument: 0 rows (must NOT drop the column filter)

Expected (per the shared spec):

• Every phase completes without error. An empty name argument is a valid filter that matches nothing — not an invalid-argument error.
• NULL/unset schema argument is unconstrained and returns rows, proving the fixture catalog is populated — so phase 2's zero rows are caused by the "" semantics, not by an empty scope.
• An empty schema argument matches only "" — no schema is named "", so zero rows.
• An empty catalog argument matches only "" — zero rows. It must NOT be reinterpreted as "all catalogs" (the widening measured in databricks-odbc#204).
• An empty table argument matches only "" — the table filter must not be dropped.
• NULL/unset column argument returns the table's columns, proving the table is populated — so phase 6's zero rows are caused by the "" semantics.
• An empty column argument matches only "" — the column filter must not be dropped.
• The zero-row table-listing results are correctly shaped, not degenerate: the metadata call's normal column schema is reported so a client can bind columns before fetching zero rows. ODBC: 5 columns, TABLE_CAT first. Other drivers: the same column schema their non-empty table-listing result carries.
• Likewise for the zero-row column listing. ODBC: 19 columns, COLUMN_NAME 4th. Other drivers: the same column schema their non-empty column-listing result carries.

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-odbc/pull/208 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-python; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
• Coverage PR carrying the reproducing xfail test(s): https://github.com/databricks/databricks-driver-test/pull/1163