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)