[jira] [Created] (IMPALA-7892) Explicit cast state lost for numeric literals on rewrite

["Paul Rogers (JIRA)" <ji...@apache.org>]

Paul Rogers created IMPALA-7892:
-----------------------------------

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


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)