You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "Paul Rogers (JIRA)" <ji...@apache.org> on 2019/03/01 18:16:00 UTC

[jira] [Assigned] (IMPALA-7855) Inconsistent typing of original/rewritten numeric expressions

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

Paul Rogers reassigned IMPALA-7855:
-----------------------------------

    Assignee:     (was: Paul Rogers)

> Inconsistent typing of original/rewritten numeric expressions
> -------------------------------------------------------------
>
>                 Key: IMPALA-7855
>                 URL: https://issues.apache.org/jira/browse/IMPALA-7855
>             Project: IMPALA
>          Issue Type: Improvement
>          Components: Frontend
>    Affects Versions: Impala 3.0
>            Reporter: Paul Rogers
>            Priority: Minor
>
> When writing unit tests, created the following query:
> {code:sql}
> with
>   query1 (a, b) as (
>     select 1 + 1 + id, 2 + 3 + int_col from functional.alltypestiny)
> insert into functional.alltypestiny (id, int_col)
>   partition (month = 5, year = 2018)
>   select * from query1
> {code}
> The above fails with the following error:
> {noformat}
> ERROR: AnalysisException: Possible loss of precision for target table 'functional.alltypestiny'.
> Expression 'query1.a' (type: BIGINT) would need to be cast to INT for column 'id'
> {noformat}
> The following does work (for planning, may not actually execute):
> {code:sql}
> with
>   query1 (a, b) as (
>     select
>       cast(1 + 1 + id as int),
>       cast(2 + 3 + int_col as int)
>     from functional.alltypestiny)
> insert into functional.alltypestiny (id, int_col)
>   partition (month = 5, year = 2018)
>   select * from query1
> {code}
> What this says is the the planner selected type {{BIGINT}} for the (rewritten) expression {{2 + id}} where {{id}} is of type {{INT}}. {{BIGINT}} is a conservative guess: adding 2 to the largest {{INT}} could overflow and require a {{BIGINT}}.
> Yet, for such a simple case, such aggressive type promotion may be overly cautious.
> To verify that this is an issue, let's try something similar with Postgres to see if it is as aggressive.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org