[
https://issues.apache.org/jira/browse/CALCITE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16234432#comment-16234432
]
Julian Hyde commented on CALCITE-2026:
--------------------------------------
bq. 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?
I just don't know, but I suspect the impact would be major. The constraint on
row type has been around a long time and it helps us, most of the time. If we
strengthen a field from INT to INT NOT NULL then every RexInputRef that
references that field will have to change. (Again, strictness of types has
served us well, most of the time.)
My favored approach these days is to add a predicate (constraint) "x IS NOT
NULL" even though the type of x remains "INT".
The philosophy in Hive was (maybe still is?) that everything is nullable. But
for Calcite, I have always felt that knowing nullability is very important. But
I know feel that every other predicate you can deduce is important also. So, an
interesting approach would be to double down on predicates: stop using
{{RelDataType.isNullable()}} and represent nullability through predicates
alone. Thus a rule could not change type, but it could generate something with
more predicates, including adding a "x IS NOT NULL" or "x > 10" predicate.
> 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)
