[ https://issues.apache.org/jira/browse/CALCITE-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700363#comment-16700363 ]
Vladimir Sitnikov commented on CALCITE-2632: -------------------------------------------- [~kgyrtkirk], could you please clarify how this differs from CALCITE-1367 ? > Add hashCode and equals implementations to RexNode > --------------------------------------------------- > > Key: CALCITE-2632 > URL: https://issues.apache.org/jira/browse/CALCITE-2632 > Project: Calcite > Issue Type: Bug > Reporter: Zoltan Haindrich > Assignee: Zoltan Haindrich > Priority: Major > > Right now RexNode doesn't have any equals or hashCode functions; which makes > it rely on the default implementation. > But when we are writing simplification logics we sometimes forget to use > {{toString()}} during comparisions and may try to rely on pure equals: > * there is a [Set of > RexNode-s|https://github.com/apache/calcite/blob/5b16e23dff03e5eaed80642ae91e28ebf806e6b0/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L1104] > during {{AND}} simplification and in [RexUtil as > well|https://github.com/apache/calcite/blob/5b16e23dff03e5eaed80642ae91e28ebf806e6b0/core/src/main/java/org/apache/calcite/rex/RexUtil.java#L321] > * I've by mistake just written rexNode.equals(otherRexNode) during the > implementation of CALCITE-1413 > * I've just bumped into the same thing...that > [RexUtil.andNot|https://github.com/apache/calcite/blob/5b16e23dff03e5eaed80642ae91e28ebf806e6b0/core/src/main/java/org/apache/calcite/rex/RexUtil.java#L1888] > is also rely on it....and I think those comparisions go back a while > (~3years at least) ; and a bug is not appeared from it because this > comparision is in most cases false. -- This message was sent by Atlassian JIRA (v7.6.3#76005)