[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-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

• PARAMQUERY-021 [thrift]: DecimalParameter with explicit precision/scale renders DECIMAL(scale,precision) instead of DECIMAL(precision,scale), so a declared DECIMAL(10,2) target is sent as DECIMAL(2,10) and the server rejects it (INVALID_PARAMETER_MARKER_VALUE.INVALID_DATA_TYPE, SQLSTATE 22023)
  • failing test: test_decimal_target_type_never_truncates_bound_scale (see the coverage PR diff under tests/)
• PARAMQUERY-021 [sea]: DecimalParameter with explicit precision/scale renders DECIMAL(scale,precision) instead of DECIMAL(precision,scale), so a declared DECIMAL(10,2) target becomes DECIMAL(2,10) and the kernel rejects the bind with ProgrammingError "DECIMAL scale must be in 0..=precision"
  • failing test: test_decimal_target_type_never_truncates_bound_scale (see the coverage PR diff under tests/)
• PARAMQUERY-021: DecimalParameter with explicit precision/scale renders the cast expression as DECIMAL(scale,precision) instead of DECIMAL(precision,scale), so a declared DECIMAL(10,2) target is sent as DECIMAL(2,10) and every bind with an explicitly declared decimal target fails (thrift: server INVALID_PARAMETER_MARKER_VALUE.INVALID_DATA_TYPE / SQLSTATE 22023; kernel: ProgrammingError "DECIMAL scale must be in 0..=precision")

Reproduce & Expected

PARAMQUERY-021 — Verify that declaring a DECIMAL/NUMERIC target type for a bound parameter never silently drops fractional digits.

Reproduce:

SELECT ? AS v
SELECT ? AS v
SELECT ? AS v

Expected (per the shared spec):

• All three binds prepare and execute successfully.
• (a) The declared DECIMAL(10,2) accommodates the value, so the parameter rides as that decimal type and the value compares numerically equal to 123.45 with both fractional digits intact.
• (b) THE CORE GUARANTEE: with no declared scale, the value is still 123.45 -- NOT 123. Assert the value, not the reported column type: a conforming driver may legitimately deliver this as a decimal the server inferred from the literal OR as the lossless text/string form, so the type is implementation latitude while the VALUE is the contract.
• (c) The value's own scale (4) is authoritative over the under-declared target scale (2): all four fractional digits survive. A result of 123.45 (or 123) is a truncation violation.

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