[coverage] Conformance findings: PARAMQUERY-021

[peco-engineer-bot]

Summary

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

Findings

• PARAMQUERY-021 [thrift, sea]: setObject with a Types.FLOAT target rides as the Databricks 4-byte FLOAT instead of the 8-byte DOUBLE the spec requires (Types.FLOAT and Types.REAL collapse to one wire type), silently narrowing double-precision binds
  • failing test: testTargetTypeDrivesWireTypeAcrossScalarTypes (see the coverage PR diff under tests/)

Reproduce & Expected

PARAMQUERY-021 — Verify the declared SQL target type — not the bound value's own native/buffer type — determines the type the parameter rides as on the wire, across the scalar and temporal target set. Binding the SAME textual value against different target types must yield differently-typed result columns for a bare marker projection.

Reproduce:

SELECT ? AS v

Expected (per the shared spec):

• result has exactly 1 row(s)
• col 0, row 0 == 42 (type Int32)
• full assertion contract:

result:
- row_count: 1
- column:
    index: 0
    row: 0
    type: Int32
    equals: 42
- result_column_type_matches_target: true

Context

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

[peco-engineer-bot]

🤖 engineer-bot opened a fix PR: #1636

Review before merge.