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-7966) Analyzer does not follow Decimal V1
type propagation rules
[ https://issues.apache.org/jira/browse/IMPALA-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Rogers reassigned IMPALA-7966:
-----------------------------------
Assignee: (was: Paul Rogers)
> Analyzer does not follow Decimal V1 type propagation rules
> ----------------------------------------------------------
>
> Key: IMPALA-7966
> URL: https://issues.apache.org/jira/browse/IMPALA-7966
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
> Affects Versions: Impala 3.1.0
> Reporter: Paul Rogers
> Priority: Major
>
> Consider {{AnalyzeExprsTest.TestDecimalArithmetic()}}:
> {code:java}
> // Operators between decimal and numeric types should be supported. The int
> // should be cast to the appropriate decimal (e.g. tinyint -> decimal(3,0)).
> testDecimalExpr(decimal_10_0 + " + cast(1 as tinyint)",
> ScalarType.createDecimalType(11, 0));
> testDecimalExpr(decimal_10_0 + " + cast(1 as smallint)",
> ScalarType.createDecimalType(11, 0));
> testDecimalExpr(decimal_10_0 + " + cast(1 as int)",
> ScalarType.createDecimalType(11, 0));
> testDecimalExpr(decimal_10_0 + " + cast(1 as bigint)",
> ScalarType.createDecimalType(20, 0));
> testDecimalExpr(decimal_10_0 + " + cast(1 as float)",
> ScalarType.createDecimalType(38, 9), ScalarType.createDecimalType(38, 8));
> testDecimalExpr(decimal_10_0 + " + cast(1 as double)",
> ScalarType.createDecimalType(38, 17), ScalarType.createDecimalType(38, 16));
> {code}
> This is rather cryptic: it means that the given expression should evaluate, in both Decimal V1 and V2, to the given type. The last two tests have different types for V1 and V2.
> However, the above should follow the V1 rules as explained in {{Expr.convertNumericLiteralsFromDecimal()}}:
> {noformat}
> * This function applies a heuristic that casts literal child exprs of this expr from
> * decimal to floating point in certain circumstances to reduce processing cost. In
> * earlier versions of Impala's decimal support, it was much slower than floating point
> * arithmetic.
> {noformat}
> There appears to be some bug that prevents the above from being applied. Once the rules are applied (though a change elsewhere that somehow enabled this path), the tests above all produce {{DOUBLE}} types. That is, the test should be:
> {code:java}
> testDecimalExpr(decimal_10_0 + " + cast(1 as tinyint)",
> Type.DOUBLE, ScalarType.createDecimalType(11, 0));
> testDecimalExpr(decimal_10_0 + " + cast(1 as smallint)",
> Type.DOUBLE, ScalarType.createDecimalType(11, 0));
> testDecimalExpr(decimal_10_0 + " + cast(1 as int)",
> Type.DOUBLE, ScalarType.createDecimalType(11, 0));
> testDecimalExpr(decimal_10_0 + " + cast(1 as bigint)",
> Type.DOUBLE, ScalarType.createDecimalType(11, 0));
> testDecimalExpr(decimal_10_0 + " + cast(1 as float)",
> Type.DOUBLE, ScalarType.createDecimalType(38, 8));
> testDecimalExpr(decimal_10_0 + " + cast(1 as double)",
> Type.DOUBLE, ScalarType.createDecimalType(38, 16));
> {code}
> The issue is marked as major because it may affect customer queries that expected the incorrect V1 behavior.
--
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