[
https://issues.apache.org/jira/browse/CALCITE-5646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714066#comment-17714066
]
Stamatis Zampetakis commented on CALCITE-5646:
----------------------------------------------
{{Strong.isStrong}} is a static util on top of {{Strong.isNull}}; I find it a
bit unfortunate that they have different names but anyways I agree that's not
the main point here.
There are two changes in the current PR:
* Consider nullability of inputs in isolation for introducing the {{IS NOT
NULL}} predicate; previously the rule considered that all inputs are NULL
* Introduce the IS NOT NULL predicate when the join predicate expression is
NULL or FALSE; previously the rule only checked for the join predicate to be
NULL (didn't care for FALSE)
I understand the first change and the PR provides a test demonstrating the
problem.
[~lchistov1987] what is the motivation behind the second change? Is there an
example/test case for this?
> JoinDeriveIsNotNullFilterRule incorrectly handles COALESCE in join condition
> ----------------------------------------------------------------------------
>
> Key: CALCITE-5646
> URL: https://issues.apache.org/jira/browse/CALCITE-5646
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.34.0
> Reporter: Leonid Chistov
> Assignee: Leonid Chistov
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Consider query
> {code:java}
> select t1.deptno from empnullables t1 inner join
> empnullables t2 on coalesce(t1.ename, t2.ename) = 'abc' {code}
> When JoinDeriveIsNotNullFilterRule is applied to it, it is incorrectly
> transformed to query plan
> {code:java}
> LogicalProject(DEPTNO=[$7])
> LogicalJoin(condition=[=(CASE(IS NOT NULL($1), $1, $10), 'abc')],
> joinType=[inner])
> LogicalFilter(condition=[IS NOT NULL($1)])
> LogicalTableScan(table=[[CATALOG, SALES, EMPNULLABLES]])
> LogicalFilter(condition=[IS NOT NULL($1)])
> LogicalTableScan(table=[[CATALOG, SALES, EMPNULLABLES]]) {code}
> It is not valid to deduce that join keys from the both sides cannot have null
> values. All that we can deduce from the join condition, is that they cannot
> be null in the same time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
