[coverage] Conformance findings: DATATYPE-042

[peco-engineer-bot]

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: fix(csharp): conformance findings: DATATYPE-042 (#640) adbc-drivers/databricks#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