[jira] [Commented] (CALCITE-2675) ReduceExpressionRule may leave behind altered types w.r.t nullability

["Zoltan Haindrich (JIRA)" <ji...@apache.org>]

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

Zoltan Haindrich commented on CALCITE-2675:
-------------------------------------------

My proposed solution is to remove the invocation of simplification after every replacements [ReduceExpression|https://github.com/apache/calcite/blob/fcc8bf7f44f92efb3c9a1e1f51ffc1a09cab27b9/core/src/main/java/org/apache/calcite/rel/rules/ReduceExpressionsRule.java#L794] may make...because in the end  ReduceExpression will make a final pass on the expression with the [simplifier|https://github.com/apache/calcite/blob/fcc8bf7f44f92efb3c9a1e1f51ffc1a09cab27b9/core/src/main/java/org/apache/calcite/rel/rules/ReduceExpressionsRule.java#L549] - which is already capable of [wrapping expression into cast armor to protect against nullability changes|https://github.com/apache/calcite/blob/fcc8bf7f44f92efb3c9a1e1f51ffc1a09cab27b9/core/src/main/java/org/apache/calcite/rex/RexUtil.java#L2657]

Notes:

* HepRuleCall checks for type [equivavalence|
https://github.com/apache/calcite/blob/fcc8bf7f44f92efb3c9a1e1f51ffc1a09cab27b9/core/src/main/java/org/apache/calcite/plan/hep/HepRuleCall.java#L57]; I think narrowing the nullability should be allowed - I think it might also help other parts 
* unfortunately RelBuilder may "cover up" for this bug in some cases - by simplifying earlier…(I think calling simplify during tree building is a little bit too greedy - I think that the optimizer should be the one doing all the optimization)


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