rubenada commented on a change in pull request #1157: [CALCITE-2969] Improve
design of join-like relational expressions
URL: https://github.com/apache/calcite/pull/1157#discussion_r281037677
##########
File path:
core/src/main/java/org/apache/calcite/adapter/enumerable/EnumerableJoinRule.java
##########
@@ -71,26 +71,25 @@
EnumerableRules.LOGGER.debug(e.toString());
return null;
}
+ } else {
+ RelNode newRel;
+ try {
+ newRel = EnumerableHashJoin.create(
+ left,
+ right,
+ info.getEquiCondition(left, right, cluster.getRexBuilder()),
+ join.getVariablesSet(),
+ join.getJoinType());
+ } catch (InvalidRelException e) {
+ EnumerableRules.LOGGER.debug(e.toString());
+ return null;
+ }
+ if (!info.isEqui()) {
+ newRel = new EnumerableFilter(cluster, newRel.getTraitSet(),
+ newRel, info.getRemaining(cluster.getRexBuilder()));
+ }
Review comment:
@danny0405 If I am not mistaken, since right now there is no "JOIN
type=ANTI", the antiJoin is supported via:
- either with a LEFT JOIN + a filter to retain only those elements with the
right part NULL
- or with a Correlate with SemiJoinType ANTI
In any case, you're right, in the current version we never generate an anti
EnumerableXXX; but with this PR it could be theoretically possible (e.g. via
RelBuilder#join method). In that situation, I think it would be safer throwing
an UnsupportedOperationException rather than running the EnumerableXXX methods
and returning a wrong result.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
