I have extended the logic to support all the symmetrical operators(=, <> ..) and the binary comparison operators (>=, < ..), not only just RexInputRef. Customized sql operator can also benefit. [1]
The way is to compare the operands with SqlKind first then fallback to their hashcode (eargely computed). Add a SqlOperator interface is not that feasible because most of the operators share the same class (for example, SqlBinaryOperator) with different SqlKind. Instead, the current code has a special SqlKind to distinguish the operators we want to normalize which I think is a better way. Eagerly computed hashcode for operand should not be a problem because sooner or later the hashcode would be computed in the digest cache of the planner and the RexCall already has a hashcode cache. We actually don’t really need to care about what the operands sort algorithm is, only if: • the algorithm is deterministic • It can cover most of the cases, like the user defined function • It does not affect the performance too much [1] https://github.com/apache/calcite/pull/2065 Best, Danny Chan 在 2020年7月15日 +0800 PM12:10，dev@calcite.apache.org，写道： > > Sql operators like EQUALS, NOT_EQUALS, AND, OR should return false to > indicate they are not input order sensitive.
