[ https://issues.apache.org/jira/browse/CALCITE-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ASF GitHub Bot updated CALCITE-5387: ------------------------------------ Labels: pull-request-available (was: ) > type-mismatch on nullability in JOIN_PUSH_TRANSITIVE_PREDICATES > --------------------------------------------------------------- > > Key: CALCITE-5387 > URL: https://issues.apache.org/jira/browse/CALCITE-5387 > Project: Calcite > Issue Type: Bug > Affects Versions: 1.30.0 > Reporter: Ian Bertolacci > Priority: Major > Labels: pull-request-available > > If the the join operands have the same core type, but different nulabilities, > then an exception is thrown during CoreRules.JOIN_PUSH_TRANSITIVE_PREDICATES > because the types "mismatch". > For example: > {{`select * from Query.Test as t join (select * from QUERY.JoinTable as j > where j.ID > 10) as j on j.ID = t.C2`}} > Here, ID is {{`BIGINT NOT NULL`}} and C2 is {{`BIGINT`}} > Initial plan: > {code} > 14:LogicalProject(ID=[$0], C1=[$1], C2=[$2], C3=[$3], C4=[$4], C5=[$5], > C6=[$6], C7=[$7], ID0=[$8], C10=[$9]) > 13:LogicalJoin(condition=[=($8, $2)], joinType=[inner]) > 9:QueryTableScan(table=[[QUERY, Test]], fields=[[0, 1, 2, 3, 4, 5, 6, 7]]) > 12:LogicalProject(ID=[$0], C1=[$1]) > 11:LogicalFilter(condition=[>($0, 10)]) > 10:QueryTableScan(table=[[QUERY, JoinTable]], fields=[[0, 1]]) > {code} > Exception and stack-trace: > {code} > type mismatch: > ref: > BIGINT NOT NULL > input: > BIGINT > java.lang.AssertionError: type mismatch: > ref: > BIGINT NOT NULL > input: > BIGINT > at org.apache.calcite.util.Litmus$1.fail(Litmus.java:32) > at org.apache.calcite.plan.RelOptUtil.eq(RelOptUtil.java:2211) > at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:129) > at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:61) > at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:114) > at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:144) > at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:61) > at org.apache.calcite.rex.RexCall.accept(RexCall.java:189) > at org.apache.calcite.rel.core.Filter.isValid(Filter.java:125) > at org.apache.calcite.rel.core.Filter.<init>(Filter.java:81) > at > org.apache.calcite.rel.logical.LogicalFilter.<init>(LogicalFilter.java:69) > at > org.apache.calcite.rel.logical.LogicalFilter.create(LogicalFilter.java:114) > at > org.apache.calcite.rel.core.RelFactories$FilterFactoryImpl.createFilter(RelFactories.java:345) > at org.apache.calcite.tools.RelBuilder.filter(RelBuilder.java:1737) > at org.apache.calcite.tools.RelBuilder.filter(RelBuilder.java:1697) > at > org.apache.calcite.rel.rules.JoinPushTransitivePredicatesRule.onMatch(JoinPushTransitivePredicatesRule.java:88) > at > org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:337) > at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:556) > at > org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:420) > at > org.apache.calcite.plan.hep.HepPlanner.executeRuleCollection(HepPlanner.java:286) > at > org.apache.calcite.plan.hep.HepInstruction$RuleCollection$State.execute(HepInstruction.java:105) > at > org.apache.calcite.plan.hep.HepPlanner.lambda$executeProgram$0(HepPlanner.java:211) > at > com.google.common.collect.ImmutableList.forEach(ImmutableList.java:406) > at > org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:210) > at > org.apache.calcite.plan.hep.HepProgram$State.execute(HepProgram.java:118) > at > org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:205) > at > org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:191) > {code} > My thinking is that checking if the two types are equal is not meaningful. > Instead what should happen is that the whole expression is type checked from > scratch using the new operand type. > Even if the new and original operant types are different (in any ways) so > long as the expression successfully type-checks, then the expression is safe > to use. > Or maybe I'm just using the rule wrong. -- This message was sent by Atlassian Jira (v8.20.10#820010)