[coverage] Conformance findings: PARAMQUERY-021

xfail đang bị lỗi có tên là “DECIMAL target — a scale-less DECIMAL declaration must not truncate the value’s fractional digits” và được tham chiếu trong tests/ ở coverage PR 1179. Bắt đầu bằng cách xác định đường dẫn binding tham số Thrift cho DBSQLParameterType.DECIMAL và chạy coverage test trên connector. Hoàn tất khi các DECIMAL target được khai báo, không có scale và khai báo thiếu đều giữ nguyên mọi chữ số phần thập phân mà không bị cắt ngắn.

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-021 [thrift]: Thrift path truncates a scale-less DECIMAL target: '123.45' bound as DBSQLParameterType.DECIMAL rides with scale 0, so SELECT :v returns 123, destroying the fractional digits
  • failing test: DECIMAL target — a scale-less DECIMAL declaration must not truncate the value’s fractional digits [xfail: thrift] (see the coverage PR diff under tests/)
• PARAMQUERY-021: Thrift path truncates a scale-less DECIMAL target: '123.45' bound as DBSQLParameterType.DECIMAL is sent with scale 0, so SELECT :v returns 123 instead of 123.45, silently destroying the value's fractional digits (the SEA/kernel path returns 123.45 correctly)

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