[C++][Compute] Binary kernels should consider decimal scale constraints when matching

[zanmato1984]

Describe the bug, including details regarding any error messages, version, and platform.

This is revealed by a regressed test in #47284. I did some trace back and put my finding here.

The issue

There was a reported issue #40126. In short, an expression add(decimal128(30, 3), decimal128(20, 9)) fires some internal DCHECK.

The root cause

The DispatchExact of function add considers the kernel with signature add(decimal128(*), decimal128(*)) as a match, ignoring the precision and scale "constraint" for this kernel. Later when the kernel's Init method is invoked, it complains that scale of the first argument (3) is not the same as the second (9) - the "constraint".

The fix (#40223)

• Before: Binding a function call expression will first do DispatchExact, then fail-over to DispatchBest if an exact match isn't found. (As the root cause says, DispatchExact did find an exact match for this case.)
• After: When an exact match is found, also try to invoke the kernel's Init method. And if that fails, fail-over to DispatchBest. Given that our arithmetic function does decent precision and scale promotion in DispatchBest (which is nice), proper implicit casts are applied to the arguments and the execution is fine.

What's not right

• The fix is essentially to tolerate the error in Init and to fail-over to DispatchBest. This may discard the real error thrown in Init - though it is likely that the error would be thrown again after DispatchBest, other error may happen subsequently and hides the original one. UT in GH-47268: [C++][Compute] Fix discarded bad status for call binding #47284 is an example.
• Ideally we should let DispatchExact fail immediately as long as the arguments don't qualify the constraint other than merely type checks, i.e., the precision/scale equality "constraint". This way, the binding naturally fails over to DispatchBest, without having to try to invoke the Init ahead. As a result, the error thrown in Init is properly preserved and propagated.

What's hard

It's currently a fundamental limitation in our kernel matching mechanism to apply extra constraints other than doing simply type checks. That prevents us from being able to fail DispatchExact immediately. This is also common for most parametric types like decimals. Related issue:

• [C++] Acero produces unexpected output type for add function on decimals #35843
• [C++] Why arrow decimal divide precision and scale is not correct? #39875
• [C++] Decimal divide promotion rule output wrong precision and scale in expression Bind when scale1 >= scale2 #40911
• [C++] Decimal types array compare with different scales make error results #41011
• [C++][Compute] Inaccurate calculation results will be produced when the 'cases' arrays of 'case_when' have different Decimal types #41336

Component(s)

C++

[zanmato1984]

Issue resolved by pull request 47297
#47297