[coverage] Conformance findings: DATATYPE-042

Start with the coverage PR diff under tests/ and the failing test named test_untyped_null_column_reports_string_type, then trace how cursor.description derives schema types for live and empty results. Verify both SELECT NULL and CAST(NULL AS STRING) report the same STRING type in both paths, while preserving the stated row, column, name, and null-value assertions.

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

• DATATYPE-042 [sea]: Over the Rust kernel (SEA), an untyped NULL column (SELECT NULL, SQL VOID) reports cursor.description type_code 'null' instead of the connector's STRING type, while its CAST(NULL AS STRING) sibling in the same result set reports 'string' — self-inconsistent and divergent from the Thrift path; affects both the live-data and empty-result schema paths
  • failing test: test_untyped_null_column_reports_string_type (see the coverage PR diff under tests/)
• DATATYPE-042: Over the Rust kernel (SEA), an untyped NULL column (SELECT NULL, SQL VOID) passes the wire type through and reports cursor.description type_code 'null' instead of the connector's STRING type, while a CAST(NULL AS STRING) sibling in the same result set reports 'string' — self-inconsistent, and divergent from the Thrift path which reports 'string'; affects both the live-data (Arrow-batch-derived) and empty-result (manifest-derived) schema paths

Reproduce & Expected

DATATYPE-042 — Verify that an UNTYPED NULL column -- SELECT NULL (SQL type VOID) -- reports the driver's STRING type on the result-set schema, identically to a CAST(NULL AS STRING) sibling selected by the SAME…

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):

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

result:
- label: live_row
  row_count: 1
- label: live_row
  column_count: 2
- label: live_row
  column:
    index: 0
    name: untyped_null
- label: live_row
  column:
    index: 1
    name: typed_null_string
- label: live_row
  column:
    name: untyped_null
    is_null: true
- label: live_row
  column:
    name: typed_null_string
    is_null: true
- label: live_row
  untyped_null_reports_string_type:
    columns:
    - untyped_null
    - typed_null_string
    match_each_other: true
- label: empty_result
  row_count: 0
- 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
  untyped_null_reports_string_type:
    columns:
    - untyped_null
    - typed_null_string
    match_each_other: true

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-sql-kernel/pull/235 — 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/1223