[jira] [Created] (CALCITE-5387) type-mismatch on nullability in JOIN_PUSH_TRANSITIVE_PREDICATES

["Ian Bertolacci (Jira)" <ji...@apache.org>]

Ian Bertolacci created CALCITE-5387:
---------------------------------------

             Summary: 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
            Reporter: Ian Bertolacci


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)