[
https://issues.apache.org/jira/browse/CALCITE-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16576851#comment-16576851
]
Vladimir Sitnikov commented on CALCITE-2455:
--------------------------------------------
It looks like the change is invalid.
1) Here's how one can create nullable `coalesce` (with helper methods from
CALCITE-2462)
This test passes on current master by the way.
{code:java}
@Test public void simplifyNullableCoalesce() {
// Cast is to ensure coalesce deduces nullable type
RexNode nullableCoalesce = coalesce(abstractCast(literal("X"),
nullable(tVarchar())));
assertTrue(nullableCoalesce + " isNullable",
nullableCoalesce.getType().isNullable());
RexNode simplified = simplify(nullableCoalesce);
assertEquals("simplify(" + nullableCoalesce + ")",
"'X' NOT NULL",
simplified + (simplified.getType().isNullable() ? "" : " NOT NULL"));
RexNode simplifyPT = simplify.simplifyPreservingType(nullableCoalesce);
assertEquals("simplifyPreservingType(" + nullableCoalesce + ")",
"CAST('X'):VARCHAR CHARACTER SET \"ISO-8859-1\" COLLATE
\"ISO-8859-1$en_US$primary\"",
simplifyPT + (simplifyPT.getType().isNullable() ? "" : " NOT NULL"));
}
{code}
2) Apparently simplify(...) is allowed to alter the result type. That is why
simplifyCoalesce is allowed to alter the type. Call site should use
simplifyPreservingType(...) when exact type match is required.
> 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)
