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

Julian Hyde commented on CALCITE-2455:
--------------------------------------

[~vvysotskyi] I’m not 100% sure why the Coalesce call is initially nullable. 
But I create the call when dealing with USING, a rewrite that happens at the 
SqlNode level, before we have validated types available.

The LATERAL keyword might also be confusing Calcite. When applied to the first 
item in the FROM clause it is valid (I believe) but has no effect.

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

Reply via email to