Antoine Pitrou
Antoine Pitrou
I'm lukewarm about the approach here. Silently casting to the max precision discards metadata about the input; it also risks producing errors further down the line (if e.g. the max...
> Two problems with just validating afterward: First, I'd expect in reasonable cases for the validation to fail. A sum of 1m decimals of approximately the same size you'd expect...
> Notably, this lack of overflow checking also applies to integer sums in arrow: Yes, and there's already a bug open for it: https://github.com/apache/arrow/issues/37090
@khwilson I'm still not sure this is actually desirable (@zanmato1984 what do you think?). What I think is definitely desirable is to check for overflow when doing sum/mean/product of decimals,...
> As for the mean and product, there's a few actions we could take: > * Status quo: Input type is the same as output type > * Promote both...
> If I understand the code correctly, what happens for the mean for decimals is that it first computes the sum by using the underlying `+` of the Decimal type,...
Issue resolved by pull request 44387 https://github.com/apache/arrow/pull/44387
Thank you @SergeyRyabinin !
> This will eventually make it easier to support Windows through the Meson configuration Why is that?
It would be nice to try applying those changes on the CMake side as well. I agree that it would be good hygiene to have to mark exported symbols explicitly.