Support different scales for decimal binary math functions

[theirix]

Which issue does this PR close?

• Closes Improve scale support for binary decimal operations #19621.

Rationale for this change

A helper calculate_binary_math and UDFs relying on it could behave strangely if the scales of inputs and outputs are different. Original logic didn't fully handle it.

So let's introduce calculate_binary_math_decimal and calculate_binary_math_numeric functions with a proper handling of arguments of different scales and type casting for input and output arguments.

They supersede calculate_binary_math and calculate_binary_math_decimal because they have a slightly different functor signature that automatically passes the effective precision and scale (even if rescaled). The rest is compatible.

What changes are included in this PR?

• New functions
• Port existing UDFs to new functions

Are these changes tested?

• Existing unit tests
• SLTs

Are there any user-facing changes?

Older functions could be deprecated. Since they are a part of the public interface of datafusion-functions, I just placed a comment without a full-fledged deprecate macro. Up to discussion whether it should be used

[theirix]

Recent related changes: #18525 and #19384 . Epic #18889

[Jefffrey]

I'm having trouble understanding the rationale here; log, power and round at most have one decimal input, and only round preserves the decimal type whereas the others will return floats anyway. So all this handling for getting precision/scale of left/right inputs, adjusting the scale of the output decimal, seems unused?

Also for round we have a PR relating to altering precision/scale:

• fix: increase ROUND decimal precision to prevent overflow truncation #19926

[theirix]

I'm having trouble understanding the rationale here; log, power and round at most have one decimal input, and only round preserves the decimal type whereas the others will return floats anyway. So all this handling for getting precision/scale of left/right inputs, adjusting the scale of the output decimal, seems unused?

For most of these functions, agree, only one argument is decimal, so we execute the decimal/non-decimal case with code for adjusting both scales untouched.

Overall, I can see the following benefits:

• simplifying a caller code by duplicating non-obvious logic to this helper
• for decimal/non-decimal case, it performs casting of input and output types, so parameter scale is not lost when operating on a native type
• for decimal outputs, it removes the burden of setting the precision and scale on output
• for array cases, it is hard to write manual code of scaling to output type (not always a default Decimal(38,10)), so cast_array_to does it for the caller
• providing effective scale and precision of a type to the user-provided kernel without capturing it from arguments

So, symmetric functions like gcd/lcm (WIP), mod, div, etc benefit most from this PR.

From the first glance, a log function can be greatly simplified by dropping unscale_to_* calls in kernels and extra casting.

For pow, originally it was Dec x Float -> Dec, but since introducing a fallback to the float version from #19369 (still thinking when it is necessary), it is less relevant.

Also for round we have a PR relating to altering precision/scale:

* [fix: increase ROUND decimal precision to prevent overflow truncation #19926](https://github.com/apache/datafusion/pull/19926)

Yes, I discovered it recently. I am wondering whether it could also be simplified using this PR, since it handles different input and output precisions and scales.

[Jefffrey]

I agree log can be greatly simplified, and it's something I'd love to get around to eventually (same for power), however I'm not sure if this is the way to do it; the code introduced here at a glance is not trivial and it doesn't solve any use case at hand (in that nothing is being simplified by this PR).

Perhaps it would be easier to see the use case if one of the functions which could benefit from this are refactored to use it in a way that has clear benefits over the existing calculate_binary_decimal_math? As this PR is, it looks like substituting the function being called, but not much else changes for the callers?