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 17:52:00 UTC

[jira] [Assigned] (IMPALA-7949) BinaryPredicate rewrite results in double cast

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

Paul Rogers reassigned IMPALA-7949:
-----------------------------------

    Assignee:     (was: Paul Rogers)

> BinaryPredicate rewrite results in double cast
> ----------------------------------------------
>
>                 Key: IMPALA-7949
>                 URL: https://issues.apache.org/jira/browse/IMPALA-7949
>             Project: IMPALA
>          Issue Type: Bug
>          Components: Frontend
>    Affects Versions: Impala 3.1.0
>            Reporter: Paul Rogers
>            Priority: Minor
>
> Consider the existing unit test: {{ExprRewriteRulesTest.TestNormalizeBinaryPredicatesRule}}, with this SELECT expression:
> {code:sql}
> cast(0 as double) = id
> {code}
> The existing test case simply does a "toSql" on the rewritten expression, suppressing implicit casts, expecting:
> {code:sql}
> id = CAST(0 AS DOUBLE)
> {code}
> However, if we examine the AST itself, or render the rewritten expression showing implicit casts, we see we get:
> {code:sql}
> CAST(id AS DOUBLE) = CAST(CAST(0 AS DOUBLE) AS DOUBLE)
> {code}
> In this particular case, the double-case it benign as the constant-folding rule, if enabled, will remove the two casts. But, if the value were a column, the double casts would exist in the plan sent to the, resulting in an unnecessary extra step.
> The expected behavior is the function argument type propagation would not insert a cast if it is not needed.
> Researching a bit more, it seems this is an artifact of recent changes in {{toSql()}}. In the {{NumericLiteral}}, we always display the type as a cast. The query specified a cast also, so the outer cast comes from the original SQL, the inner from pushing the cast type into the numeric literal.
> This is not so much a bug as it is a muddling of the semantics. There is no reason to push the type into the numeric literal if an explicit cast exists.



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