mihaibudiu opened a new pull request, #3663: URL: https://github.com/apache/calcite/pull/3663
This is another attempt to fix [CALCITE-2067]. PR #572 attempted to do this, but wasn't merged about 8 years ago. This PR includes very similar changes. The current implementation of RexLiteral uses a BigDecimal value to store DOUBLE values. This is a problem for 2 reasons: - it loses precision, since some FP values cannot be stored precisely in decimal notation - it cannot represent special FP values, such as -0.0, Infinity, or NaN With this PR these issues are solved. As a side-effect, this enables the simplification engine to simplify some expressions that it couldn't before, such as expressions that produce special FP values. Objections to the original PR which can be seen here: https://issues.apache.org/jira/browse/CALCITE-2067 include the fact that this "changes the SQL language accepted by Calcite." I want to preempt this objection: this change does not affect the parser or SqlNode, only RexNode. So it is only useful for *evaluation* and *optimization*. Moreover, if we will add support to the parser for special values as suggested in https://issues.apache.org/jira/browse/CALCITE-6058, we will certainly need a way to represent them in the RelNode IR. I claim that the changes in this PR are necessary for that goal. The most unpleasant effect of this PR is to slightly change the semantics of some programs that used FP values before. These programs were in fact buggy, but third parties may have taken dependencies on these bugs. This kind of behavior was discovered by comparing results produced by Postgres (or Java) with Calcite on FP functions; the results were slightly off. The BigDecimal-induced rounding was the problem. I also think that the constructor for RexLiteral that creates a literal for a DOUBLE type from a BigDecimal should be deprecated. I didn't do it in this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
