Describe the bug, including details regarding any error messages, version, and platform.
On current main (e611f48081), expression binding can incorrectly treat mixed decimal arguments to coalesce as an exact kernel match. This bypasses the decimal normalization in CoalesceFunction::DispatchBest and leaves the bound expression without the required cast to a common decimal type.
For a schema containing:
left: decimal128(3, 2)
right: decimal128(4, 3)
binding:
call("coalesce", {field_ref("left"), field_ref("right")})
currently produces:
instead of:
coalesce(cast(left, decimal128(4, 3)), right)
With left = [1.23, null] and right = [null, 2.345], executing the incorrectly bound expression fails with:
Type error: All types must be compatible, expected: decimal128(3, 2), but got: decimal128(4, 3)
The expected result is a decimal128(4, 3) array containing [1.230, 2.345].
Calling DispatchBest directly already normalizes these arguments correctly. The problem is that expression binding tries DispatchExact first, and the broad decimal varargs signature accepts the mixed concrete decimal types before DispatchBest can insert the cast.
This appears to be another instance of the exact-dispatch constraint problem addressed more generally by #47287 and the MatchConstraint mechanism introduced in #47297.
Component(s)
C++
Describe the bug, including details regarding any error messages, version, and platform.
On current
main(e611f48081), expression binding can incorrectly treat mixed decimal arguments tocoalesceas an exact kernel match. This bypasses the decimal normalization inCoalesceFunction::DispatchBestand leaves the bound expression without the required cast to a common decimal type.For a schema containing:
binding:
currently produces:
instead of:
With
left = [1.23, null]andright = [null, 2.345], executing the incorrectly bound expression fails with:The expected result is a
decimal128(4, 3)array containing[1.230, 2.345].Calling
DispatchBestdirectly already normalizes these arguments correctly. The problem is that expression binding triesDispatchExactfirst, and the broad decimal varargs signature accepts the mixed concrete decimal types beforeDispatchBestcan insert the cast.This appears to be another instance of the exact-dispatch constraint problem addressed more generally by #47287 and the
MatchConstraintmechanism introduced in #47297.Component(s)
C++