[jira] [Resolved] (CALCITE-583) Operator `||` mishandled ANY type

["Julian Hyde (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CALCITE-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julian Hyde resolved CALCITE-583.
---------------------------------
       Resolution: Fixed
    Fix Version/s:     (was: next)
                   1.1.0-incubating

Fixed in http://git-wip-us.apache.org/repos/asf/incubator-calcite/commit/8afdd01f.

> Operator `||` mishandled ANY type 
> ----------------------------------
>
>                 Key: CALCITE-583
>                 URL: https://issues.apache.org/jira/browse/CALCITE-583
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Sean Hsuan-Yi Chu
>            Assignee: Julian Hyde
>             Fix For: 1.1.0-incubating
>
>         Attachments: CALCITE-583.1.patch, CALCITE-583.2.patch
>
>
> For instance, 
> select  ANY type || ANY type ... leads assertion error from:
> assert (precision >= 0)        || (precision == RelDataType.PRECISION_NOT_SPECIFIED);
> (SqlTypeFactoryImpl.java( line: 62))
> Essentially, it is because, SqlReturnTypeInference of `||` is DYADIC_STRING_SUM_PRECISION. When doing inference for the return type, there is one data field in DYADIC_STRING_SUM_PRECISION called "precision", which is calculated as arg0.precison + arg1.precision.
> However, for ANY type, the precision is defined as -1. So the above calculation will give "-2" for ANY type operands, in turn, breaking up the assertion.
> Moreover, `||` can fail when the two operands have different types (e.g., ANY type || String). In the No schema system, ANY type can be quite prevalent. For example, select  ANY type || string || ANY type ... where, in addition to two ANY types on two sides, we have a string in between.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)