-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CALCITE-3866] "numeric field overflow" when running the generated SQL in PostgreSQL #1867
Conversation
478714a
to
7c7ca98
Compare
LGTM +1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
Hi, @wenhuitang, could you please rebase and resolve the conflict? We can merge it into 1.23.0. |
I investigated the return type for sum function in Hive[1] and Spark[2]. It seems they both compute the precision as |
…L in PostgreSQL (Wenhui Tang)
Thanks a lot. I have rebased this pr. IMO, as for computing precision as Math.min(MAX_PRECISION, inputPrecision + 10), I did not find any theory or standard for it. To avoid the problem completely, it would be ok with max precision. |
LGTM! |
Pull request for https://issues.apache.org/jira/browse/CALCITE-3866
As for aggregate function sum, most of the time, its return type is equal to its operand's type, but if its operand's type has precision, the precision of the result may be larger than the oeprans's type. So may be we can set precision to the Max value if the oeprand's type has precision, especially for the type decimal.