[
https://issues.apache.org/jira/browse/CALCITE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16234403#comment-16234403
]
Jesus Camacho Rodriguez commented on CALCITE-2026:
--------------------------------------------------
I am thinking whether it is more convenient to rely on _addCasts_ logic or the
rule should create an additional Project operator (though redundant) on top of
existing one? Having the correct value for nullability can help the optimizer
triggering some additional rules.
[~julianhyde], I guess since a rule cannot produce an expression with a
different row type (and nullable property is part of that type), it is the
responsibility of other code to do those transformations, e.g, RelFieldTrimmer?
Or is there another way?
Would it make sense to relax the condition in the optimizer so the row type is
compared without taking into account nullability? What would be the
implications of changing that?
> AssertionError when ProjectReduceExpressionsRule simplifies project
> expressions
> -------------------------------------------------------------------------------
>
> Key: CALCITE-2026
> URL: https://issues.apache.org/jira/browse/CALCITE-2026
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Volodymyr Vysotskyi
> Assignee: Julian Hyde
> Priority: Major
>
> When applying ProjectReduceExpressionsRule on project which expression has a
> non-nullable type, but after simplifying expression is null, the query fails
> with the assertion error:
> {noformat}
> java.lang.AssertionError: Type mismatch:
> rel rowtype:
> RecordType(INTEGER EXPR$0) NOT NULL
> equivRel rowtype:
> RecordType(INTEGER NOT NULL EXPR$0) NOT NULL
> at org.apache.calcite.util.Litmus$1.fail(Litmus.java:31)
> ~[calcite-core-1.13.0.jar:1.13.0]
> at org.apache.calcite.plan.RelOptUtil.equal(RelOptUtil.java:1868)
> ~[calcite-core-1.13.0.jar:1.13.0]
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:855)
> ~[calcite-core-1.13.0.jar:1.13.0]
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> ~[calcite-core-1.13.0.jar:1.13.0]
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:1767)
> ~[calcite-core-1.13.0.jar:1.13.0]
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:135)
> ~[calcite-core-1.13.0.jar:1.13.0]
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> ~[calcite-core-1.13.0.jar:1.13.0]
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule$ProjectReduceExpressionsRule.onMatch(ReduceExpressionsRule.java:268)
> ~[calcite-core-1.13.0.jar:1.13.0]
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> ~[calcite-core-1.13.0.jar:1.13.0]
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> ~[calcite-core-1.13.0.jar:1.13.0]
> at
> org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:368)
> ~[calcite-core-1.13.0.jar:1.13.0]
> {noformat}
> The similar bug was described in CALCITE-1502, since there was a problem with
> non-nullable and nullable types in different case branches, but this bug
> appears when project expression is transformed into the expression with
> nullable type.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
