[
https://issues.apache.org/jira/browse/TRAFODION-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15398060#comment-15398060
]
ASF GitHub Bot commented on TRAFODION-2047:
-------------------------------------------
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.
> add SQL syntax support to INTERSECT
> -----------------------------------
>
> Key: TRAFODION-2047
> URL: https://issues.apache.org/jira/browse/TRAFODION-2047
> Project: Apache Trafodion
> Issue Type: New Feature
> Reporter: liu ming
> Assignee: liu ming
> Fix For: 2.1-incubating
>
>
> INTERSECT is a common SQL syntax.
> Trafodion should support it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)