[coverage] Conformance findings: PARAMQUERY-023

[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-023 [thrift]: A character value bound with a scale-less DECIMAL target is sent as the bare type "DECIMAL", so the server's default DECIMAL(10,0) silently truncates "123.45" to 123 (getDecimalTypeString derives DECIMAL(p,s) only for BigDecimal/Number values)
  • failing test: testUnderSpecifiedDecimalTargetPreservesValueLosslessly (see the coverage PR diff under tests/)
• PARAMQUERY-023 [sea]: Same truncation on the SEA path: DatabricksSdkClient.mapToParameterListItem sends the bare "DECIMAL" type for a character value with a scale-less DECIMAL target, so "123.45" returns as 123
  • failing test: testUnderSpecifiedDecimalTargetPreservesValueLosslessly (see the coverage PR diff under tests/)
• PARAMQUERY-023: A character value bound with a scale-less DECIMAL/NUMERIC target (setObject(i, "123.45", Types.DECIMAL)) is sent with the bare wire type "DECIMAL", so the server's default DECIMAL(10,0) silently truncates the fractional digits to 123; getDecimalTypeString only derives DECIMAL(p,s) for BigDecimal/Number values. Affects both thrift and sea.

Reproduce & Expected

PARAMQUERY-023 — Verify that a DECIMAL/NUMERIC target with NO declared scale never causes the bound value's fractional digits to be dropped.

Reproduce:

• Sub-case 1 — bind the text value "123.45" with a DECIMAL target that declares a
  precision but NO scale, and execute SELECT ? AS v.
• Sub-case 2 — bind a value carrying its own scale of 4 (decimal 123.4567; ODBC:
  a SQL_C_NUMERIC struct with precision 10, scale 4) with a DECIMAL target that
  declares no scale, and execute SELECT ? AS v.

Expected (per the shared spec):

• Neither binding raises — in particular no numeric-out-of-range / 22003 style error for the under-specified target
• The value is preserved losslessly. Returning 123 (scale forced to 0) is the truncation this case exists to catch.
• The value's own scale (4) governs — a scale-less declared target must not reduce it, and the reported type must not disagree with the value.

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