[
https://issues.apache.org/jira/browse/CALCITE-6210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816797#comment-17816797
]
Mihai Budiu commented on CALCITE-6210:
--------------------------------------
The problem with my approach is that other dialects of SQL may want a different
behavior.
Copying here the relevant discussion from github:
[~gortiz] said:
does it actually fix the issue?
The issue was the assertion error when casting STRING to VARBINARY. I'm not an
expert on Apache Calcite, so I may be wrong, but it looks to me that this is
only fixing the issue in the Enumerable convention.
What about other cases? For example in Apache Pinot we found this issue when
executing SqlToRelConverted.trimUnusedFields. Specifically, when the expression
is a literal like CAST('sometext' as VARBINARY).
As said, I'm a noob here, but I don't see a call to
RexToLixTranslator.translateCast in our stacktrace.
how can we change the implementation used?
Specifically, this PR defines an arbitrary way to transform from String to
Binary, but other systems may want to apply different logic to do so. In Pinot
case we apply this cast by interpreting the String as hex codified. I guess we
could override the implementation of stringToBinary, but I'm not sure.
[~mbudiu] said:
These are very good questions. Indeed, this PR the "Enumerable" implementation.
But that implementation is special, because it is the one used when Calcite
optimizations simplify a query plan. In particular, the optimization rule
PROJECT_REDUCE_EXPRESSIONS uses this code to simplify constant expressions.
As far as I understand, the behavior of built-in SQL functions and casts in
Calcite is not configurable to depend on the dialect being compiled.
If you want a different behavior of these casts in different dialects the only
solution may be to never let Calcite simplify the code (assuming that is
possible - I don't understand all the paths on which code is simplified, some
simplifications are used even when you do not use PROJECT_REDUCE_EXPRESSIONS).
If you can avoid Calcite optimizing these cases, then the cast implementation
is purely a question of what your runtime chooses to do.
Another alternative would be to indeed "override" the function I wrote
stringToBinary, but I don't see how you can do this in a dialect-dependent
version.
Perhaps someone more knowledgeable ([~julianhyde]?) about the Calcite
architecture can answer this question: "can the behavior of a cast made to be
dialect-dependent?" If yes, what is the right way to do it?
> Cast to VARBINARY causes an assertion failure
> ---------------------------------------------
>
> Key: CALCITE-6210
> URL: https://issues.apache.org/jira/browse/CALCITE-6210
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.36.0
> Reporter: Mihai Budiu
> Priority: Minor
> Labels: pull-request-available
>
> This test in SqlOperatorTest:
> {code:java}
> SqlOperatorFixture f = fixture();
> f.checkScalar("CAST('00' AS VARBINARY)", "00", "VARBINARY NOT NULL");
> {code}
> Causes the following assertion failure:
> {code}
> java.lang.AssertionError: value 00 does not match type class
> org.apache.calcite.avatica.util.ByteString
> at
> org.apache.calcite.linq4j.tree.ConstantExpression.<init>(ConstantExpression.java:51)
> at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:585)
> 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.DeclarationStatement.accept(DeclarationStatement.java:45)
> at
> org.apache.calcite.linq4j.tree.DeclarationStatement.accept(DeclarationStatement.java:27)
> at
> org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:426)
> 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:2272)
> 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)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
