[coverage] Conformance findings: METADATA-005

Start with the METADATA-005 xfail tests under tests/ in coverage PR #1413 and compare the intended behavior with reference PR #291. Locate the Node.js driver's SEA getTypeInfo() implementation and its metadata result construction. Done means the Thrift-facing result matches the specified 18-column, 20-row shape and the conformance tests pass.

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-nodejs. 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-nodejs) is fixed, then flips green as a tripwire.

Findings

• METADATA-005 [sea]: SEA getTypeInfo() synthesises a non-canonical type catalogue: COLUMN_SIZE instead of PRECISION, AUTO_UNIQUE_VALUE instead of AUTO_INCREMENT, an extra 19th INTERVAL_PRECISION column, and 23 rows (extra VARCHAR/TIMESTAMP_NTZ/INTERVAL/VARIANT/VARBINARY/NUMERIC, VOID missing) instead of the canonical 18-column / 20-row Thrift TGetTypeInfoResp shape
  • failing test: getTypeInfo — canonical 20-row corpus, order, cell values, NULLABLE=1 / getTypeInfo — canonical 18-column TGetTypeInfoResp layout (PRECISION/AUTO_INCREMENT, no INTERVAL_PRECISION) (see the coverage PR diff under tests/)
• METADATA-005: SEA getTypeInfo() synthesises a non-canonical type catalogue: emits COLUMN_SIZE instead of PRECISION and AUTO_UNIQUE_VALUE instead of AUTO_INCREMENT, adds a 19th INTERVAL_PRECISION column, and returns 23 rows (extra VARCHAR/TIMESTAMP_NTZ/INTERVAL/VARIANT/VARBINARY/NUMERIC, VOID missing) instead of the canonical 18-column / 20-row Thrift TGetTypeInfoResp shape, so a wrapper switching Thrift→SEA sees its public getTypeInfo() result change

Reproduce & Expected

METADATA-005 — Validates GetTypeInfo returns the canonical Thrift/HiveServer2 getTypeInfo result for the supported Databricks SQL data types: the 18-column schema, the 20-row type corpus, and the per-type cell va…

Reproduce:

• Call GetTypeInfo via IsMetadataCommand statement (C# only)

Expected (per the shared spec):

• GetTypeInfo completes successfully
• Result contains type information
• C# Thrift path only
• Exactly the canonical Thrift/HiveServer2 getTypeInfo column count — not 19. A synthesised result must not add an extra column (the pre-fix kernel carried a 19th INTERVAL_PRECISION column that the Thrift response does not have). Scoped to the Thrift/JDBC-style surface: ODBC SQLGetTypeInfo has its own spec-fixed column set.
• Column names AND their order match the Thrift getTypeInfo result exactly. The two renames matter for wrappers that read the result positionally or by name: PRECISION (not COLUMN_SIZE) at index 2 and AUTO_INCREMENT (not AUTO_UNIQUE_VALUE) at index 11. Scoped to the Thrift/JDBC-style surface (see SURFACE SCOPE in the description): a driver whose type-info surface is ODBC SQLGetTypeInfo asserts its own canonical column set instead — record that per-driver answer in this entry's status cells.
• The type catalogue has exactly 20 rows — the Thrift SparkGetTypeInfoUtil.supportedType corpus. Not "at least one type": a synthesised catalogue must neither drop rows nor add types Thrift does not report (the pre-fix kernel listed 24 rows including VARCHAR, TIMESTAMP_NTZ, the two INTERVAL types, VARIANT and VARBINARY, which Thrift does not).
• The first 17 rows are exactly these type names, in exactly this order — the leading run of the 20-row SparkGetTypeInfoUtil.supportedType corpus. Row ORDER is part of the contract, not just membership: VOID is row 0, and a catalogue that reorders the corpus (or omits VOID) diverges from Thrift even if the same names are present. Only a PREFIX is enumerated because the reference PR diff available when this entry was authored is truncated after CHAR; rows 18–20 are pinned by the row_count: 20 assertion above and should be read off the reference implementation when implementing.
• Per-type cell values match Thrift. DATA_TYPE codes are java.sql.Types values and must agree with the driver's getColumns type mapping (the historical drift this pins: FLOAT reported as REAL (7), STRING as LONGVARCHAR (-1), BOOLEAN as BIT (-7)). PRECISION is non-null only for the numeric types (and is NULL for STRING/BINARY/CHAR — a synthesised catalogue must not substitute i32::MAX or 255). SEARCHABLE is 3 (typeSearchable) for every type except the complex types ARRAY / MAP / STRUCT, which are 0 (typeNoSearch). CASE_SENSITIVE is true only for STRING.
• Every row reports NULLABLE = 1 (typeNullable), matching Thrift — not 2 (typeNullableUnknown), which the pre-fix synthesised catalogue used for every row.

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-sql-kernel/pull/291 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-nodejs; 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/1413