[
https://issues.apache.org/jira/browse/IMPALA-7793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675587#comment-16675587
]
Paul Rogers commented on IMPALA-7793:
-------------------------------------
This issue identified two problems.
First, V2 of Decimal support does not perform type propagation, but V1 does.
This would appear to be a regression. That is, as shown above, in V1 the
planner worked out that it needed to cast 1.8 to DECIMAL(38,38) (which then
overflowed.) In V2, no such type inference is done and the user must explicitly
include a cast. A bit of research is needed to determine if this is a feature
(perhaps to be compatible with some other SQL version) or a bug (a regression.)
Second, during expression rewrite, the constant folding rule will try to
execute {{CAST(1.8 AS DECIMAL(38,38))}} but will fail (due to overflow). The
constant folding rule simply leaves the expression unchanged. All subsequent
rules need to be very careful to treat this kind of expression as a
non-constant. For example, the {{coalesce()}} example above works only because
the planner does not rewrite it. Add a bit of logic to remove constants (as was
done as part of the project that found the bug) and the statement is rewritten
as just the cast (the first non-null value) which caused the behavior described
here.
The upshot is that this is not a problem with {{CASE}} per-se, it is a subtle
issue with how the planner needs to handle failed constant folding expressions.
The fix is to mark seemingly-constant expression as non-constant (using
existing flags) if it fails to execute so that downstream rules do not treat
the expression as a constant and do rewrites based on that assumption.
> CASE must not rewrite CAST(literal AS type) exprs
> -------------------------------------------------
>
> Key: IMPALA-7793
> URL: https://issues.apache.org/jira/browse/IMPALA-7793
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
> Affects Versions: Impala 3.0
> Reporter: Paul Rogers
> Priority: Major
>
> The test suite {{QueryTest/decimal-exprs}} contains the following test:
> {code:sql}
> set decimal_v2=false;
> set ENABLE_EXPR_REWRITES=false;
> select coalesce(1.8, cast(0 as decimal(38,38)))
> {code}
> Which produces this result:
> {noformat}
> +------------------------------------------+
> | coalesce(1.8, cast(0 as decimal(38,38))) |
> +------------------------------------------+
> | 0.00000000000000000000000000000000000000 |
> +------------------------------------------+
> WARNINGS: UDF WARNING: Decimal expression overflowed, returning NULL
> {noformat}
> Notice that the "1.8" overflowed when being put into a {{DECIMAL(38,38)}}
> type. (The precision and range are both 38, meaning all digits are after the
> decimal point.)
> The {{coalesce()}} function caught the overflow, treated it as a {{NULL}},
> and selected the second value from the list, which is 0.
> Very good. Now, try the equivalent CASE form (from MPALA-7655):
> {noformat}
> select CASE WHEN 1.8 IS NOT NULL THEN 1.8 ELSE cast(0 as decimal(38,38)) END;
> +-----------------------------------------------------------------------+
> | case when 1.8 is not null then 1.8 else cast(0 as decimal(38,38)) end |
> +-----------------------------------------------------------------------+
> | NULL |
> +-----------------------------------------------------------------------+
> WARNINGS: UDF WARNING: Decimal expression overflowed, returning NULL
> {noformat}
> Apparently, the overflow somehow caused the {{ELSE}} clause to not fire.
> This one is likely a bug in the BE code generation. Though, tried the
> {{CASE}} query with a variety of options:
> {noformat}
> set disable_codegen=true;
> and
> set disable_codegen=false;
> set disable_codegen_rows_threshold=0;
> and
> set disable_codegen_rows_threshold=10;
> {noformat}
> In all cases, the {{CASE}} produced the wrong result. Also tried wrapping the
> expression {{1.8 IS NOT NULL}} in a variety of forms: {{IS TRUE}}, {{IS NOT
> FALSE}}. None of this worked correctly.
> The result of this bug is the the above-mentioned test case fails in a build
> that contains IMPALA-7655.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
