Latest Results
fix(core): bound decimal arithmetic precision at 38 instead of failing to plan
Decimal add/sub/mul/div inference hard-errored whenever the ideal result
precision exceeded 38, so ordinary chained decimal arithmetic failed to
plan. This breaks TPC-H Q1 (`price * (1 - discount) * (1 + tax)`,
precision 61) and Q9 (subtraction, precision 39):
Cannot infer supertypes for multiply on types: Decimal[38,4],
Decimal[23,2] result precision: 61 exceed bounds of [1, 38]
Decimal128 is backed by an i128, so 38 digits is a hard physical limit;
the ideal type simply is not representable. Instead of erroring, cap the
precision at 38 and shrink the scale only as far as needed to stay valid
(precision >= scale >= 0, precision >= 1) via a shared bound_decimal128
helper. This mirrors Daft's own decimal aggregation supertypes
(try_sum_supertype / try_product_supertype use Decimal128(_, s) =>
Decimal128(38, s)) and the behaviour of Spark and DuckDB.
Division also preserves the quotient's integer digits when bounding: its
max(6, p1 + s2 + 1) term inflates the scale far beyond what the operands
need, so keeping that scale under a 38 cap would leave zero integer
digits and null out every whole-number result.
Results that already fit within 38 digits are unchanged. No kernel change
is required because evaluation casts both operands to the inferred output
type, so the Decimal128 kernel inherits the bounded dtype.
Fixes #7601hello-peter-tang:fix/7601-decimal-precision-overflow Latest Branches
0%
hello-peter-tang:fix/7560-count-only-positional-deletes 0%
hello-peter-tang:fix/7601-decimal-precision-overflow 0%
easyrev:feat/sql-cross-join © 2026 CodSpeed Technology