mihaibudiu commented on code in PR #4727:
URL: https://github.com/apache/calcite/pull/4727#discussion_r2666592183
##########
core/src/main/java/org/apache/calcite/adapter/enumerable/RexImpTable.java:
##########
@@ -4842,6 +4844,58 @@ private static class IsNotDistinctFromImplementor
extends AbstractRexCallImpleme
}
}
+ /** Implementor for the {@code IS DISTINCT FROM} SQL operator. */
+ private static class IsDistinctFromImplementor extends
AbstractRexCallImplementor {
+ IsDistinctFromImplementor() {
+ super("is_distinct_from", NullPolicy.NONE, false);
+ }
+
+ @Override public RexToLixTranslator.Result implement(
+ final RexToLixTranslator translator,
+ final RexCall call,
+ final List<RexToLixTranslator.Result> arguments) {
+ final RexToLixTranslator.Result left = arguments.get(0);
+ final RexToLixTranslator.Result right = arguments.get(1);
+
+ // Generated expression:
+ // left IS NULL ?
+ // (right IS NULL ? FALSE : TRUE) : -> when left is null
+ // (right IS NULL ? TRUE : -> when left is not null
+ // !left.equals(right)) -> when both are not null,
compare values
+ final Expression equalsExpression =
Review Comment:
I didn't say that the current implementation is risky, but that in general
it's risky to derive the implementation for an operator X from the
implementation of a similar, but not identical, Y. This can be problematic when
adding new functionality which is not properly overriden in the derived class,
and inherits the base class incorrectly.
The common abstract class approach makes it less likely that this will
happen.
There can also be problems when using visitors if the derived classes forget
to derive the accept() methods.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
