[
https://issues.apache.org/jira/browse/CALCITE-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Quesada Lopez updated CALCITE-2898:
-----------------------------------------
Description:
{{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
EquiJoin)
was:
{{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 condition will NOT be detected as an
equi-join and will be returned as it were a non-equijoin.
This can lead to undesired consequences, e.g in {{JoinInfo#of}} which will
return NonEquiJoinInfo instead of an EquiJoinInfo.
> 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
>
> {{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
> EquiJoin)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
