[
https://issues.apache.org/jira/browse/CALCITE-7827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18119735#comment-18119735
]
Sean Broeder commented on CALCITE-7827:
---------------------------------------
For this change, I've followed the promotion precedent set in
SqlTypeFactoryImpl#leastRestrictiveSqlType for DECIMAL types.
Plain INTEGER/BIGINT vs. approximate numeric is unaffected, since
those never carry more precision than a REAL holds.
> 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)
