[
https://issues.apache.org/jira/browse/CALCITE-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6651:
------------------------------------
Labels: pull-request-available (was: )
> Ignore SqlLiteral in implicit Integer type cast
> -----------------------------------------------
>
> Key: CALCITE-6651
> URL: https://issues.apache.org/jira/browse/CALCITE-6651
> Project: Calcite
> Issue Type: Bug
> Reporter: suibianwanwan
> Assignee: suibianwanwan
> Priority: Major
> Labels: pull-request-available
>
> The integer type implicit cast for IN sub-query is supported in CALCITE-5156.
> But for SqlLiteral in IN, we should not force its type cast. In the following
> comment, in LogicalValue, we keep the type information in RelNode
> {code:java}
> private RexLiteral convertLiteral(SqlLiteral sqlLiteral,
> Blackboard bb, RelDataType type) {
> RexNode literalExpr = exprConverter.convertLiteral(bb, sqlLiteral);
> if (!(literalExpr instanceof RexLiteral)) {
> assert literalExpr.isA(SqlKind.CAST);
> RexNode child = ((RexCall) literalExpr).getOperands().get(0);
> assert RexLiteral.isNullLiteral(child);
> // NOTE jvs 22-Nov-2006: we preserve type info
> // in LogicalValues digest, so it's OK to lose it here
> return (RexLiteral) child;
> }
> //.....
> }{code}
> Take the following SQL as an example:
> {code:java}
> SELECT empno
> FROM emp AS e
> WHERE cast(e.empno as bigint) in (130, 131, 132, 133, 134) {code}
> {code:java}
> LogicalProject(EMPNO=[$0])
> LogicalJoin(condition=[=($9, $10)], joinType=[inner])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], EMPNO0=[CAST($0):BIGINT NOT
> NULL])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{0}])
> LogicalValues(tuples=[[{ 130 }, { 131 }, { 132 }, { 133 }, { 134
> }]]){code}
> The type of the Literal is inferred from the type of the LogicalValues.
> However, if you cast the SqlLiteral to Integer during the validation process,
> it will result in the following Bad Plan. In the case of too many Values,
> optimizations such as RexSimplify, pullUpPredicate will consume a lot of time
> compared to past plans.
> {code:java}
> LogicalProject(EMPNO=[$0])
> LogicalJoin(condition=[=($9, $10)], joinType=[inner])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], EMPNO0=[CAST($0):BIGINT NOT
> NULL])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{0}])
> LogicalUnion(all=[true])
> LogicalValues(tuples=[[{ 130 }]])
> LogicalValues(tuples=[[{ 131 }]])
> LogicalValues(tuples=[[{ 132 }]])
> LogicalValues(tuples=[[{ 133 }]])
> LogicalValues(tuples=[[{ 134 }]]) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
