[
https://issues.apache.org/jira/browse/CALCITE-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16691388#comment-16691388
]
Zoltan Haindrich commented on CALCITE-2675:
-------------------------------------------
[~danny0405] Yes, I believe the same - this issue could probably happen in any
planner.
I feel that the main problem with the sql2rel rewrite is that it may cover up
for bugs like this - and makes it harder to reproduce - but sure I'm not
against; it was just an observation.
To be on the same side do you think that passing a NOT NULL column to something
which accepts also NULLs could be considered "type equivalence"? I believe
yes...but the current implementation requires type equality.
The removal of that simplification call is redundant; because after that there
will be a full pass of simplification on all nodes - that's why there are
absolutely no test output changes; although that simplification is now gone.
I also feel that the simplification done there was a little bit out of place as
I think it may cause repeated simplification of the same node: consider a
rewrite at depth D ; then every upstream visitation of [this
method|https://github.com/apache/calcite/blob/fcc8bf7f44f92efb3c9a1e1f51ffc1a09cab27b9/core/src/main/java/org/apache/calcite/rel/rules/ReduceExpressionsRule.java#L794]
will run a full simplification of the underlying subtree...which will result
in D runs of simplification on the leaf node - and probably around {{~D**2}}
operations in the visited number of RexNodes.
> ReduceExpressionRule may leave behind altered types w.r.t nullability
> ---------------------------------------------------------------------
>
> Key: CALCITE-2675
> URL: https://issues.apache.org/jira/browse/CALCITE-2675
> Project: Calcite
> Issue Type: Bug
> Reporter: Zoltan Haindrich
> Assignee: Zoltan Haindrich
> Priority: Major
>
> If a simplification could happen after some [ReduceExpression
> rewrite|https://github.com/apache/calcite/blob/fcc8bf7f44f92efb3c9a1e1f51ffc1a09cab27b9/core/src/main/java/org/apache/calcite/rel/rules/ReduceExpressionsRule.java#L794];
> the simplification result may have a slightly different type in nullability.
> {code}
> @Test public <T> void testReduceCaseNullabilityChange() throws Exception {
> HepProgram program = new HepProgramBuilder()
> .addRuleInstance(ReduceExpressionsRule.FILTER_INSTANCE)
> .addRuleInstance(ReduceExpressionsRule.PROJECT_INSTANCE)
> .build();
> try (Hook.Closeable a =
> Hook.REL_BUILDER_SIMPLIFY.add(Hook.propertyJ(false))) {
> checkPlanning(program,
> "select case when empno = 1 then 1 when 1 IS NOT NULL then 2 else
> null end as qx "
> + "from emp");
> }
> {code}
> Exposed by CALCITE-1413 changes; I'm not sure if there is any other
> variations for which the same could happen.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
