[jira] [Commented] (CALCITE-2898) RelOptUtil#splitJoinCondition must consider RexFieldAccess referencing RexInputRef

["Ruben Quesada Lopez (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16818724#comment-16818724 ] 

Ruben Quesada Lopez commented on CALCITE-2898:
----------------------------------------------

As explained in the [mailing list|https://mail-archives.apache.org/mod_mbox/calcite-dev/201904.mbox/%3CCAEZ%2BV3s7xFJFsXtHOC%2B7m%3DRGbw-SYUYR2ZTm842Bui3dezVc5Q%40mail.gmail.com%3E], my proposed change was working on my scenario only because I was implementing [Semi]Join via Correlation, as soon as I switched to Enumerable[Semi]Join, the execution did not return the expected results. Therefore, as [~julianhyde] said, this change will do harm, so I'll close this ticket and the linked PR.

> RelOptUtil#splitJoinCondition must consider RexFieldAccess referencing RexInputRef
> ----------------------------------------------------------------------------------
>
>                 Key: CALCITE-2898
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2898
>             Project: Calcite
>          Issue Type: Bug
>    Affects Versions: 1.18.0
>            Reporter: Ruben Quesada Lopez
>            Assignee: Ruben Quesada Lopez
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{RelOptUtil#splitJoinCondition}} "Splits out the equi-join components of a join condition, and returns what's left (remaining join filters that are not equijoins)". This works fine in case of RexInputRef operands in the condition (e.g. $0 = $1), but if any of the operands is a RexFieldAccess referencing a RexInputRef (e.g. $0 = $1.id), then the condition will NOT be detected as an equi-join and will be returned as if it were a non-equijoin. 
> This can lead to undesired consequences, e.g {{JoinInfo#of}} would return a NonEquiJoinInfo object instead of an EquiJoinInfo object, which can generate problems if, for example, we are creating a SemiJoin (which requires an EquiJoinInfo object)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)