Github user zellerh commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/623#discussion_r72684626
--- Diff: core/sql/optimizer/BindRelExpr.cpp ---
@@ -717,7 +717,7 @@ static ItemExpr *intersectColumns(const RETDesc
&leftTable,
ItemExpr *leftExpr = leftTable.getValueId(i).getItemExpr();
ItemExpr *rightExpr = rightTable.getValueId(i).getItemExpr();
BiRelat *compare = new (bindWA->wHeap())
- BiRelat(ITM_EQUAL, leftExpr, rightExpr);
+ BiRelat(ITM_EQUAL, leftExpr, rightExpr, TRUE);
--- End diff --
Here are two things I wonder: First, would it make sense to replace the
TRUE here with "leftExpr->getValueId().getType().supportsSQLnull() &&
rightExpr->getValueId().getType().supportsSQLnull()". I'm not sure we have
optimizations elsewhere that set the "special nulls" semantics back to FALSE if
one of the operands it not nullable.
Second, I wonder whether we have bugs elsewhere in the code that may not
check for the "special nulls" semantics. For example, hash and merge joins
probably can't use such predicates as equi-join predicates - one of the reasons
for the optimization above. When I look at method
ItemExpr::isAnEquiJoinPredicate() in core/sql/optimizer/OptItemExpr.cpp, I
don't see a check for that. You have an example with a NULL value that is
working, so hopefully this is not an issue, but I'm not sure how and why it
works.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
