[ 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)