[
https://issues.apache.org/jira/browse/CALCITE-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16577034#comment-16577034
]
Yuzhao Chen commented on CALCITE-2455:
--------------------------------------
[~vladimirsitnikov]
Sorry, i think {{simplifyCoalesce}} should keep nullability just like
{{simplifyCase:}}
{code:java}
assert newOperands.size() % 2 == 1;
if (newOperands.size() == 1 || values.size() == 1) {
final RexNode last = Util.last(newOperands);
if (!call.getType().equals(last.getType())) {
return rexBuilder.makeAbstractCast(call.getType(), last);
}
return last;
}
{code}
Cause we use {{RexSimplify.simplify}} directly in rules but
{{simplifyPreservingType}} is only a tool method for now.
If we assert that {{RexSimplify.simplify}} can modify nullability, at least we
should have a parameter to control it but not do it silently.
> simplifyCoalesce of constant should match nullability
> -----------------------------------------------------
>
> Key: CALCITE-2455
> URL: https://issues.apache.org/jira/browse/CALCITE-2455
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.17.0
> Reporter: Yuzhao Chen
> Assignee: Julian Hyde
> Priority: Major
> Fix For: 1.18.0
>
>
> After CALCITE-2227, we will not replace Coalesce to Case When for natural
> join, when we use ReduceExpressionRule for our plan for Coalesce with
> constant, the nullability will chage( from nullable to notnull), this will
> cause VolcanoPlanner to throw error.
> Should i fix this? or we should not use this rule in VolcanoPlanner?
> This is the error thrown sql :
> {code:java}
> select * from lateral (select * from scott_emp) as e
> join (table scott_dept) using (deptno)
> where e.deptno = 10 {code}
> The plan before ReduceExpressionRule:
> {code:java}
> LogicalProject(deptno=[COALESCE($7, $8)], empno=[$0], ename=[$1], job=[$2],
> mgr= [$3], hiredate=[$4], sal=[$5], comm=[$6], dname=[$9], loc=[$10])
> +- LogicalFilter(condition=[=($7, 10)])
> +- LogicalJoin(condition=[=($7, $8)], joinType=[inner])
> :- LogicalProject(empno=[$0], ename=[$1], job=[$2], mgr=[$3], hiredate=[$4],
> sal=[$5], comm=[$6], deptno=[$7])
> : +- LogicalTableScan(table=[[scott_emp]])
> +- LogicalProject(deptno=[$0], dname=[$1], loc=[$2])
> +- LogicalTableScan(table=[[scott_dept]])
> {code}
> The plan after:
> {code:java}
> LogicalProject(deptno=[10], empno=[$0], ename=[$1], job=[$2], mgr=[$3],
> hiredate=[$4], sal=[$5], comm=[$6], dname=[$9], loc=[$10])
> +- LogicalFilter(condition=[=($7, 10)])
> +- LogicalJoin(condition=[=($7, $8)], joinType=[inner])
> :- LogicalProject(empno=[$0], ename=[$1], job=[$2], mgr=[$3], hiredate=[$4],
> sal=[$5], comm=[$6], deptno=[$7])
> : +- LogicalTableScan(table=[[scott_emp]])
> +- LogicalProject(deptno=[$0], dname=[$1], loc=[$2])
> +- LogicalTableScan(table=[[scott_dept]])
> {code}
> We can see that the deptno's nullability changes from nullable to not null.
> And we encounter an type error when using ReduceExpressionRule in
> VolcanoPlanner.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
