[
https://issues.apache.org/jira/browse/IMPALA-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Rogers resolved IMPALA-7892.
---------------------------------
Resolution: Fixed
> Explicit cast state lost for numeric literals on rewrite
> --------------------------------------------------------
>
> Key: IMPALA-7892
> URL: https://issues.apache.org/jira/browse/IMPALA-7892
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
> Affects Versions: Impala 3.0
> Reporter: Paul Rogers
> Assignee: Paul Rogers
> Priority: Minor
>
> Consider the following SQL:
> {code:sql}
> SELECT CAST(1 AS INT) as C FROM alltypestiny
> {code}
> The expression contains an explicit cast that cannot be optimized away during
> rewrites. The cast tells us that the user wants the value 1 as an {{INT}},
> not as its “natural” type as {{TINYINT}}.
> The NumericLiteral type has an “explicit cast” flag that is set sometimes.
> However, the expression rewriter does not set it:
> {code:java}
> String query = "SELECT CAST(1 AS INT) AS c" +
> " from functional.alltypestiny";
> AnalysisContext ctx = createAnalysisCtx();
> ctx.getQueryOptions().setEnable_expr_rewrites(true);
> SelectStmt select = (SelectStmt) AnalyzesOk(query, ctx);
> Expr expr = select.getSelectList().getItems().get(0).getExpr();
> assertEquals(ScalarType.INT, expr.getType());
> assertTrue(expr instanceof NumericLiteral);
> assertTrue(((NumericLiteral) expr).isExplicitCast());
> {code}
> The last test fails because the NumericLiteral is not marked as explicitly
> cast.
> If the analyzer were to "reset" analysis for the node, we would lose the fact
> that the user wanted an {{INT}}, and the type would revert to {{TINYINT}},
> causing instability, a small change in the analyzer can produce a different
> query result.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
