Fix DECIMAL parameter cast size for exponent-notation and negative values

[winklemad]

Description

DecimalParameter.calculate_decimal_cast_string (parameters/native.py) infers the DECIMAL(precision, scale) to cast a bound Decimal to by string-splitting str(value) on ".". That miscounts two forms str(Decimal) legitimately produces, so the generated type can't hold the bound value.

Exponent notation — str() emits E for many magnitudes (e.g. Decimal("1500").normalize() is Decimal("1.5E+3"); .scaleb(), arithmetic, and scientific input do the same):

cursor.execute("SELECT ?", [Decimal("1500").normalize()])
# infers DECIMAL(5,4)  -- the "E+3" is counted as 4 fractional digits
# but 1500 needs DECIMAL(4,0); DECIMAL(5,4) max is ±9.9999 -> overflow
#   -> error in ANSI mode, or silently NULL in legacy mode

Negative values — the leading - is counted as an integer digit, over-widening every negative by one precision digit, which becomes a hard failure at the boundary:

Decimal("-" + "9" * 38)   # a valid DECIMAL(38,0)
# infers DECIMAL(39,0), which exceeds Databricks' maximum DECIMAL precision of 38
#   -> invalid cast, query fails

Both the cast type and the bound literal come from the same value, so the server can't reconcile them — a perfectly valid Decimal is rejected or silently nulled.

Fix

Derive precision/scale from Decimal.as_tuple() (sign, digits, exponent) — the exact numeric value — instead of the display string, so sign and exponent formatting no longer inflate the counts. Handles exponent notation, negatives, and sub-1 values uniformly.

Tests

The six existing test_calculate_decimal_cast_string cases are unchanged and still pass. Added regression cases for exponent notation (Decimal("1500").normalize() → DECIMAL(4,0), Decimal("1e5") → DECIMAL(6,0)) and negatives (-9…9 (38 digits) → DECIMAL(38,0), Decimal("-12.34") → DECIMAL(4,2)). tests/unit/test_parameters.py passes (60).

[aminghadersohi]

Confirming this is still needed on 4.6.0. Against a SQL warehouse, a bound Decimal("1E-18") (cast as DECIMAL(5,0)) and Decimal("1E-7") are stored as 0 without an error, and a 38-digit negative such as -99999999999999999999.999999999999999999 is rejected as DECIMAL(39,18). Sizing the cast from Decimal.as_tuple() as this PR does makes all of those round-trip exactly, including DECIMAL(38,18) at both extremes, in Core executemany and in SELECT :p. It would be great to get this reviewed.

[winklemad]

Thanks for checking this against a real warehouse, that is really helpful. Good to know the executemany and SELECT :p paths round-trip too, since those were the two I was least sure about outside the unit tests.