You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Jesus Camacho Rodriguez (JIRA)" <ji...@apache.org> on 2016/10/07 10:53:20 UTC
[jira] [Commented] (CALCITE-1417) Casts of literals
[ https://issues.apache.org/jira/browse/CALCITE-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15554792#comment-15554792 ]
Jesus Camacho Rodriguez commented on CALCITE-1417:
--------------------------------------------------
This makes a lot of sense [~julianhyde]; the more utility methods we have, the less logic we end up coding repeatedly. I can try to take a look into detail at {{DruidDateTimeUtils}} to identify what we can factor out and generalize, so we can include it in RexUtil. If you already have a proposal, I can check that too.
> Casts of literals
> -----------------
>
> Key: CALCITE-1417
> URL: https://issues.apache.org/jira/browse/CALCITE-1417
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
>
> A literal is a constant, and so a cast of a literal is also a constant, but when we do constant reduction sometimes there are errors if the cast is not valid. For example, the query
> {code}
> values cast('' as integer)
> {code}
> gives {{ExceptionInInitializerError}} and, to make matters worse, the Avatica JDBC driver does not catch the exception (because it is a {{java.lang.Error}}) and wrap it as a {{java.sql.SQLException}} as it ought to.
> Also, CALCITE-1357 added some logic (in {{DruidDateTimeUtils.leafToRanges}}) to recognize various combinations of literals, casts of literals and comparison operators, and I feel that logic would be simpler if we moved the logic into {{RexUtil}} and flattened the casts of literals to just plain literals. [~jcamachorodriguez], what do you think?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)