feat(expression): cast numeric literals to decimal type

[huan233usc]

What

Add casting of numeric literals (int, long, float, double) to a decimal target type in Literal::CastTo, so a numeric value can be used as a default for a decimal column.

Previously CastFromInt / CastFromLong / CastFromFloat / CastFromDouble had no kDecimal case and fell through to NotSupported, so a default like Literal::Int(12) or Literal::Double(9.99) for a decimal(9, 2) column was rejected. Java allows these (IntegerLiteral.to, DoubleLiteral.to, etc. scale the value to the target scale), so this brings the C++ literal cast layer to parity for numeric sources.

How

• Integer → decimal: CastIntegerToDecimal scales the integer (scale 0) up to the target scale via Decimal::Rescale(0, scale), then verifies the result fits the target precision (FitsInPrecision). Example: 12 → decimal(9,2) yields unscaled 1200 (12.00).
• Float/double → decimal: CastRealToDecimal parses the value's shortest round-tripping decimal representation (matching Java's BigDecimal.valueOf(double) via Double.toString), then rounds to the target scale with HALF_UP rounding (round half away from zero, as Java does — 2.5 → 3, -2.5 → -3), and checks precision. Non-finite values are rejected.
• Both paths reject an out-of-range decimal scale before indexing the powers-of-ten table (DecimalType does not bound its scale on construction, so decimal(9, 40) would otherwise read past the table).

Scope

Follow-up split out from the v3 default-value work (see the CastDefaultToType discussion on #793). It only extends the shared Literal::CastTo layer for numeric sources.

Testing

LiteralTest.IntegerCastToDecimal (int/long scaling, out-of-precision rejection, out-of-range scale rejection) and LiteralTest.RealCastToDecimal (float/double scaling, HALF_UP rounding incl. negative, round-down, out-of-precision and non-finite rejection), all verified fail-without / pass-with. Full expression_test passes (495 tests).

[Copilot]

Pull request overview

This PR extends Literal::CastTo to support casting numeric literals (int, long, float, double) into a decimal target type, aligning C++ literal-cast behavior with Java’s numeric-to-decimal default handling. It adds new decimal-cast logic for integer and real sources and introduces targeted unit tests to validate scaling, rounding, and rejection behavior.

Changes:

• Add integer→decimal and real→decimal cast paths in LiteralCaster, including HALF_UP rounding behavior.
• Add RescaleHalfUp helper to support HALF_UP rounding (including negative target scales) while avoiding unsafe power-of-ten indexing in some cases.
• Add new tests covering integer/real decimal casts, scale handling, rounding behavior, and error cases.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
src/iceberg/expression/literal.cc	Adds numeric→decimal casting logic and a HALF_UP rescaling helper used by Literal::CastTo.
src/iceberg/test/literal_test.cc	Adds unit tests validating integer/real casts to decimal, rounding rules, and error handling.

[wgtmac]

Decimal::FromString normalizes negative scales to 0 before this rescale, which can overflow its int128 intermediate. For example, Literal::Double(4e38).CastTo(decimal(38, 0)) may wrap 4 * 10^38 to a 38-digit value and accept the wrong literal instead of rejecting it. It also rejects representable negative-scale cases such as 1e39 -> decimal(2, -38). Could we retain the parsed coefficient and exponent scale, rescale directly to the target scale, and add regressions for both cases?

[huan233usc]

Good catch. Now I parse the coefficient and its scale directly from the to_chars output (via a small ParseRealCoefficient helper) instead of going through Decimal::FromString, which was normalizing the negative scale by multiplying the coefficient by 10^-scale and overflowing int128. The coefficient itself always fits, and RescaleHalfUp combines the exponent with the target scale and rejects true overflow. Added regressions for both 4e38 -> decimal(38, 0) (rejected) and 1e39 -> decimal(2, -38) (accepted as 10).