Zoltan Haindrich created CALCITE-2632: -----------------------------------------
Summary: 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 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)