fix: Remove power(decimal, int) code path

[neilconway]

Which issue does this PR close?

• Closes power(decimal, integer) overflow for moderate exponents #22480
• Closes power(decimal, -integer) is incorrect #22510

Rationale for this change

power(decimal, int) attempted to compute power without loss of precision. For negative exponents, the code did the computation in Float64 and then cast the result back to decimal. Unfortunately, the previous implementation got this wrong, because decimal might not have enough precision to accurately represent the result. It seems simpler to return Float64 for the negative exponent case.

We could potentially try to return decimal only for non-negative exponents and Float64 for negative exponents, but that is complicated, and also means that the code would produce different results for literal arguments vs. columnar arguments, which I think should be avoided.

On reflection, it seems simplest to just remove the power(decimal, int) code path entirely, and have power always return Float64. This also fixes another issue in the decimal code path (#22480)

What changes are included in this PR?

• Remove power(decimal, ...) support; both args will be coerced to Float64 if necessary, and the function will always return Float64
• Update SLT
• Add new test cases for power(decimal, integer) overflow for moderate exponents #22480 and power(decimal, -integer) is incorrect #22510

Are these changes tested?

Yes.

Are there any user-facing changes?

Yes, power(decimal, ...) will now return Float64.

[neilconway]

@theirix @Jefffrey curious what you think

[theirix]

Thanks for the PR, @neilconway . I had similar reflections on power recently, and this change would make sense.

Since power and log can change scale drastically, fixed-size decimal types are tricky to implement correctly without having an infinite intermediate representation like BigInt or Postgres-style infinite decimal. An ideal behaviour for me is determining whether it makes sense to return decimal values based on the arguments and scale, but it essentially shifts computation to the planning phase and doesn't work well with arrays (you can have small and large scales in the same array, but the return type has to stay the same).

Nevertheless, other scale-preserving functions like round, abs, gcd, etc still benefit from a decimal implementation since they carry the same type across operations.

[neilconway]

@theirix Yep, makes sense to me!

[Jefffrey]

makes sense; it was a nice idea to have native decimal support but the implementation complexity & edge cases made it a bit of a headache in reality 😅

[Jefffrey]

thanks @neilconway & @theirix