[ 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)