[coverage] Conformance findings: DATATYPE-041

Start with the failing test_decimal_text_rendering_without_scientific_notation in the coverage PR diff under tests/, then trace how the Python connector exposes DECIMAL values as text. Compare the intended behavior with reference PR 134; done means the DATATYPE-041 assertions pass with plain notation at the declared scale, including 0.0000001.

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

• DATATYPE-041 [thrift]: DECIMAL text surface uses scientific notation at high scale: a DECIMAL(20,7) 0.0000001 renders as "1E-7" instead of plain "0.0000001" at the declared scale, because the connector returns a decimal.Decimal whose stdlib str switches to exponent form below adjusted exponent -6 (PECOBLR-2096)
  • failing test: test_decimal_text_rendering_without_scientific_notation (see the coverage PR diff under tests/)
• DATATYPE-041 [sea]: DECIMAL text surface uses scientific notation at high scale on the SEA/kernel backend too: a DECIMAL(20,7) 0.0000001 renders as "1E-7" instead of plain "0.0000001" at the declared scale (PECOBLR-2096)
  • failing test: test_decimal_text_rendering_without_scientific_notation (see the coverage PR diff under tests/)
• DATATYPE-041: DECIMAL text surface uses scientific notation at high scale: a DECIMAL(20,7) 0.0000001 renders as "1E-7" instead of plain "0.0000001" at the declared scale, because the connector returns a decimal.Decimal whose stdlib str switches to exponent form below adjusted exponent -6 — consumers reading the column as text (CSV export, f-string/str formatting, BI tools) get an exponent form where the reference driver emits plain digits (PECOBLR-2096)

Reproduce & Expected

DATATYPE-041 — Verify that when a driver renders a DECIMAL column as text, the rendering is PLAIN decimal notation carrying the column's declared scale -- never scientific notation, never a re-scaled or truncated m…

Expected (per the shared spec):

• result has exactly 1 row(s)
• col zero_scaled, row 0 == 0
• col sub_one, row 0 == 0.5
• col neg_sub_one, row 0 == -0.05
• col sub_one_high_scale, row 0 == 1e-07
• col trailing_zeros, row 0 == 100.0
• col wide_magnitude, row 0 == 1.2345678901234568e+26
• full assertion contract:

result:
- row_count: 1
- column:
    name: zero_scaled
    equals: 0
- column:
    name: sub_one
    equals: 0.5
- column:
    name: neg_sub_one
    equals: -0.05
- column:
    name: sub_one_high_scale
    equals: 1.0e-07
- column:
    name: trailing_zeros
    equals: 100.0
- column:
    name: wide_magnitude
    equals: 1.2345678901234568e+26
- decimal_text_plain_notation:
    columns:
    - zero_scaled
    - sub_one
    - neg_sub_one
    - sub_one_high_scale
    - trailing_zeros
    - wide_magnitude

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-odbc/pull/134 — 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/1138