[coverage] Conformance findings: DATATYPE-042

先从 tests/ 下 coverage PR 中的 DATATYPE-042 expected-failure test 开始，然后将预期行为与 reference PR #644 进行比较。跟踪 databricks-sql-nodejs 如何报告两个 SELECT NULL 查询的元数据。当 live 结果和空结果都为两列报告 STRING、保留名称和 null 值，并满足列出的 row-count assertions 时，即表示完成。

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

• DATATYPE-042 [sea]: SEA/kernel reports NULL_TYPE (TTypeId 16) for an untyped SELECT NULL (VOID) result column instead of its STRING type, so it disagrees with a CAST(NULL AS STRING) sibling in the same result set; Thrift correctly reports STRING_TYPE
  • failing test: untyped NULL column is reported as STRING, matching its CAST(NULL AS STRING) sibling [sea] (see the coverage PR diff under tests/)
• DATATYPE-042: SEA/kernel reports NULL_TYPE (TTypeId 16) for an untyped SELECT NULL (VOID) result column instead of its STRING type, so the column disagrees with a CAST(NULL AS STRING) sibling in the same result set; Thrift correctly reports STRING_TYPE

Reproduce & Expected

DATATYPE-042 — Verify that an UNTYPED NULL column -- a bare SELECT NULL expression, whose Databricks SQL type is VOID (spelled NULL on some surfaces) -- is reported by the driver as its STRING type, identically t…

Reproduce:

SELECT NULL AS untyped_null, CAST(NULL AS STRING) AS typed_null_string
SELECT NULL AS untyped_null, CAST(NULL AS STRING) AS typed_null_string FROM range(1) WHERE 1 = 0

Expected (per the shared spec):

• completes without an exception
• result has 2 column(s)
• col 0 is named untyped_null
• col 1 is named typed_null_string
• result has exactly 1 row(s)
• col untyped_null, row 0 is null
• col typed_null_string, row 0 is null
• completes without an exception
• result has 2 column(s)
• col 0 is named untyped_null
• col 1 is named typed_null_string
• result has exactly 0 row(s)
• full assertion contract:

result:
- label: live_data
  no_exception: true
- label: live_data
  column_count: 2
- label: live_data
  column:
    index: 0
    name: untyped_null
- label: live_data
  column:
    index: 1
    name: typed_null_string
- label: live_data
  column_reported_type:
    name: untyped_null
    equals: STRING
- label: live_data
  column_reported_type:
    name: typed_null_string
    equals: STRING
- label: live_data
  column_reported_types_match:
    columns:
    - untyped_null
    - typed_null_string
- label: live_data
  row_count: 1
- label: live_data
  column:
    name: untyped_null
    is_null: true
- label: live_data
  column:
    name: typed_null_string
    is_null: true
- label: live_data
  column_data_agrees_with_reported_type:
    columns:
    - untyped_null
    - typed_null_string
- label: empty_result
  no_exception: true
- label: empty_result
  column_count: 2
- label: empty_result
  column:
    index: 0
    name: untyped_null
- label: empty_result
  column:
    index: 1
    name: typed_null_string
- label: empty_result
  column_reported_type:
    name: untyped_null
    equals: STRING
- label: empty_result
  column_reported_type:
    name: typed_null_string
    equals: STRING
- label: empty_result
  column_reported_types_match:
    columns:
    - untyped_null
    - typed_null_string
- label: empty_result
  row_count: 0

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/adbc-drivers/databricks/pull/644 — 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/1258