[coverage] Conformance findings: DATATYPE-042

Comece pelo diff de cobertura do PR em tests/ e pelo teste com falha chamado test_untyped_null_column_reports_string_type; em seguida, rastreie como cursor.description deriva os tipos de esquema para resultados com dados e resultados vazios. Verifique se tanto SELECT NULL quanto CAST(NULL AS STRING) reportam o mesmo tipo STRING em ambos os caminhos, preservando as asserções indicadas sobre linhas, colunas, nomes e valores nulos.

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