[
https://issues.apache.org/jira/browse/CALCITE-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu resolved CALCITE-6168.
----------------------------------
Fix Version/s: 1.37.0
Resolution: Fixed
Fixed in
https://github.com/apache/calcite/commit/ba9c840b7516acaccee20d778726c818928c40e2
> RexExecutor can throw during compilation
> ----------------------------------------
>
> Key: CALCITE-6168
> URL: https://issues.apache.org/jira/browse/CALCITE-6168
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.36.0
> Reporter: Mihai Budiu
> Priority: Minor
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> The RexExecutor is supposed to evaluate expressions at compilation time; if
> an expression causes an exception, it should be caught and the expression
> should be unchanged. The goal is to have the exception be reported at
> runtime. The executor does catch exceptions during its "execute" phase, but
> some exceptions can be caught during its "compile" phase.
> The following SqlOperatorTest will exhibit such an instance:
> {code:java}
> @Test
> void testCast() {
> final SqlOperatorFixture f = fixture();
> f.checkFails("CAST(200 as TINYINT)", "", true);
> }
> }
> {code}
> This is the relevant portion of the stack trace:
> {code}
> at
> org.apache.calcite.linq4j.tree.Primitive.checkRoundedRange(Primitive.java:383)
> at
> org.apache.calcite.linq4j.tree.Primitive.numberValue(Primitive.java:398)
> at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:575)
> at
> org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:305)
> at
> org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:39)
> at
> org.apache.calcite.linq4j.tree.TernaryExpression.accept(TernaryExpression.java:47)
> at
> org.apache.calcite.linq4j.tree.Expressions.acceptExpressions(Expressions.java:3214)
> at
> org.apache.calcite.linq4j.tree.NewArrayExpression.accept(NewArrayExpression.java:49)
> at
> org.apache.calcite.linq4j.tree.GotoStatement.accept(GotoStatement.java:64)
> at
> org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:455)
> at
> org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:340)
> at
> org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:102)
> at
> org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:68)
> at
> org.apache.calcite.rex.RexExecutorImpl.reduce(RexExecutorImpl.java:133)
> at
> org.apache.calcite.rex.RexSimplify.simplifyCast(RexSimplify.java:2265)
> at org.apache.calcite.rex.RexSimplify.simplify(RexSimplify.java:292)
> at
> org.apache.calcite.rex.RexSimplify.simplifyUnknownAs(RexSimplify.java:250)
> at
> org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:189)
> at
> org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:184)
> at
> org.apache.calcite.tools.RelBuilder.lambda$project_$7(RelBuilder.java:2050)
> {code}
> Notice that this happens during the compile stage:
> at
> org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:68)
> The simplest fix is probably to move the try/catch block earlier in the flow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
