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:51:00 UTC

[jira] [Assigned] (IMPALA-7965) FE should use "permissive" constant folding evaluation

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

Paul Rogers reassigned IMPALA-7965:
-----------------------------------

    Assignee:     (was: Paul Rogers)

> FE should use "permissive" constant folding evaluation
> ------------------------------------------------------
>
>                 Key: IMPALA-7965
>                 URL: https://issues.apache.org/jira/browse/IMPALA-7965
>             Project: IMPALA
>          Issue Type: Bug
>          Components: Frontend
>    Affects Versions: Impala 3.1.0
>            Reporter: Paul Rogers
>            Priority: Minor
>
> The FE implements "constant folding" the conversion of constant expressions into constant literals. For example, {{1 + 1}} is constant-folded to {{2}}.
> Subtle cases occur when the BE cannot evaluate the expression. For example:
> * DECIMAL-value overflow or underflow e.g. {{CAST(10 AS DECIMAL(1,0))}}
> * Illegal casts e.g. {{CAST('foo' AS TIMESTAMP)}}
> * Result strings that contain non-ASCII characters e.g. {{hex('D3')}}
> In this case, the FE does not fail the query, it just leaves the original SQL and let's the BE fail the query at runtime. (Doing so seems more of a bug than a feature, but let's set that issue aside at present.)
> There are cases in which the error is benign. Consider this case from {{ExprRewriteRulesTest.TestFoldConstantsRule()}}:
> Note that a side rule is that the result of constant folding should be the result of the BE executing the entire expression. From {{ExprRewriteRulesTest.TestFoldConstantsRule()}}:
> {code:java}
>     // Tests correct handling of strings with chars > 127. Should not be folded.
>     verifyRewrite("hex(unhex(hex(unhex('D3'))))", null);
> {code}
> This test says that the following SQL expression cannot be evaluated on the BE:
> {code:sql}
> hex(unhex(hex(unhex('D3'))))
> {code}
> But, the BE can happily evaluate the whole thing, and produce a result of {{'D3'}}. What fails is:
> {code:sql}
> unhex('D3')
> {code}
> But not:
> {code:sql}
> hex(unhex('D3'))
> {code}
> Similar reasoning applies to:
> {code:sql}
> FALSE AND CAST(20 AS DECIMAL(1,0))
> {code}
> In the present code, the entire test expression fails. But, under the, "let the BE decide" rule, the expression:
> {code:sql}
> hex(unhex(hex(unhex('D3'))))
> {code}
> Can be rewritten to:
> {code:sql}
> hex('D3')
> {code}
> The inner three functions are evaluated properly on the BE. Only the outer function fails and is preserved in the AST.



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