[
https://issues.apache.org/jira/browse/CALCITE-7827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18120251#comment-18120251
]
Sean Broeder commented on CALCITE-7827:
---------------------------------------
Thank you [~mbudiu]. Could a case be made that this is a correctness issue,
rather than a breaking change? I've added a join test that I believe should
return empty results, but without the change returns 2 values. Hopefully that
demonstrates the problem I am facing. If this is still viewed as a breaking
change rather than a correctness issue, could we perhaps introduce a
config/conformance option to change the desired behavior?
> commonTypeForBinaryComparison narrows DECIMAL vs. FLOAT/REAL comparisons
> ------------------------------------------------------------------------
>
> Key: CALCITE-7827
> URL: https://issues.apache.org/jira/browse/CALCITE-7827
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.42.0
> Reporter: Sean Broeder
> Assignee: Sean Broeder
> Priority: Major
> Labels: pull-request-available
>
> AbstractTypeCoercion#commonTypeForBinaryComparison picks the approximate
> numeric operand's own type (FLOAT/REAL) as the common type for a comparison
> between an exact numeric DECIMAL and an approximate numeric operand,
> resulting in a loss of precision.
> A 32-bit FLOAT/REAL carries only ~7 significant decimal digits. When the
> validator uses this common type to insert an implicit CAST on the DECIMAL
> operand, two genuinely different DECIMAL values can collapse onto the same
> float value and incorrectly compare equal.
> commonTypeForBinaryComparison should consider the exact numeric's type before
> blindly returning the approximate numeric's type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
