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

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-022 [thrift]: DecimalParameter renders a bound DECIMAL's wire value as str(Decimal) and derives DECIMAL(p,s) by counting that string's characters, so Decimal("1e-7") is sent as value "1E-7" with type DECIMAL(4,0) and the server rounds the value to 0 instead of binding 0.0000001 as DECIMAL(7,7)
  • failing test: test_exponent_notation_decimal_parameter_binds_as_plain_numeral (see the coverage PR diff under tests/)
• PARAMQUERY-022 [sea]: the connector sends a bound DECIMAL's value in exponent notation ("1E-7") on the SEA wire rather than the equivalent plain numeral "0.0000001"; the Rust kernel re-derives DECIMAL(7,7) so the value is NOT lost on SEA, but the plain-numeral wire form is not met (same str(Decimal) root cause as the Thrift truncation)
  • failing test: test_exponent_notation_decimal_parameter_binds_as_plain_numeral (see the coverage PR diff under tests/)
• PARAMQUERY-023 [thrift]: the Thrift path performs no client-side precision validation for a bound DECIMAL: a 39-digit value is derived as DECIMAL(39,0) and sent, failing server-side with INVALID_PARAMETER_MARKER_VALUE.INVALID_DATA_TYPE (SQLSTATE 22023) instead of raising a bind-time parameter error before any ExecuteStatement, as the Rust-kernel/SEA path correctly does
  • failing test: test_decimal_parameter_beyond_maximum_precision_rejected_before_execution (see the coverage PR diff under tests/)
• PARAMQUERY-022: DecimalParameter renders a bound DECIMAL's wire value as str(Decimal) and derives DECIMAL(p,s) by counting that string's characters, so an exponent-form value is corrupted on Thrift: Decimal("1e-7") is sent as value "1E-7" with type DECIMAL(4,0) and the server rounds it to 0 (on SEA the Rust kernel re-derives DECIMAL(7,7) so the value survives, but "1E-7" still rides the wire instead of the plain numeral "0.0000001")
• PARAMQUERY-023: the Thrift path performs no client-side precision validation for a bound DECIMAL: a 39-digit value is derived as DECIMAL(39,0) and sent, so it fails server-side with INVALID_PARAMETER_MARKER_VALUE.INVALID_DATA_TYPE (SQLSTATE 22023) instead of raising a bind-time parameter error before any ExecuteStatement, as the Rust-kernel/SEA path correctly does

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: fix: keep DECIMAL parameter scale on the Thrift backend databricks-sql-nodejs#585 — 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/2022