[coverage] Conformance findings: PARAMQUERY-022,PARAMQUERY-023

[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

• PARAMQUERY-022 [thrift]: Thrift DECIMAL parameter binding emits DECIMAL(precision,0) — scale hard-coded to 0 — so "123.45" declares decimal(3,0) instead of a scale-carrying decimal; SEA correctly emits decimal(5,2)
  • failing test: decimal target — "123.45" bound as DECIMAL comes back a decimal carrying scale, digits intact (see the coverage PR diff under tests/)
• PARAMQUERY-023 [thrift]: Thrift DECIMAL parameter binding silently TRUNCATES fractional digits: "123.45" round-trips as 123 (data corruption) via a scale-0 wire type; it neither preserves the value nor raises numeric-out-of-range, while the SEA path is lossless
  • failing test: scale-less decimal target — "123.45" is never silently truncated to 123 (see the coverage PR diff under tests/)

Reproduce & Expected

PARAMQUERY-022 — Verify a DECIMAL/NUMERIC target with a declared precision and scale sends the parameter as a DECIMAL carrying THAT precision/scale, so the bare-marker result column is a decimal of the declared shape and the fractional digits survive.

Reproduce:

SELECT ? AS v

Expected (per the shared spec):

• result has exactly 1 row(s)
• col 0, row 0 == '123.45' (type Decimal128)
• full assertion contract:

result:
- row_count: 1
- column:
    index: 0
    row: 0
    type: Decimal128
    equals: '123.45'
- result_column_type_matches_target: true

PARAMQUERY-023 — Verify a DECIMAL/NUMERIC target with NO declared scale does not silently truncate fractional digits. An under-specified decimal target must not be forced to scale 0 — the value is preserved losslessly (the reference driver keeps the lossless value-derived type and lets the server infer the decimal).

Reproduce:

SELECT ? AS v

Expected (per the shared spec):

• result has exactly 1 row(s)
• full assertion contract:

result:
- row_count: 1
- value_preserved_losslessly: '123.45'

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-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/1061