[ https://issues.apache.org/jira/browse/IMPALA-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Rogers reassigned IMPALA-7949: ----------------------------------- Assignee: (was: Paul Rogers) > BinaryPredicate rewrite results in double cast > ---------------------------------------------- > > Key: IMPALA-7949 > URL: https://issues.apache.org/jira/browse/IMPALA-7949 > Project: IMPALA > Issue Type: Bug > Components: Frontend > Affects Versions: Impala 3.1.0 > Reporter: Paul Rogers > Priority: Minor > > Consider the existing unit test: > {{ExprRewriteRulesTest.TestNormalizeBinaryPredicatesRule}}, with this SELECT > expression: > {code:sql} > cast(0 as double) = id > {code} > The existing test case simply does a "toSql" on the rewritten expression, > suppressing implicit casts, expecting: > {code:sql} > id = CAST(0 AS DOUBLE) > {code} > However, if we examine the AST itself, or render the rewritten expression > showing implicit casts, we see we get: > {code:sql} > CAST(id AS DOUBLE) = CAST(CAST(0 AS DOUBLE) AS DOUBLE) > {code} > In this particular case, the double-case it benign as the constant-folding > rule, if enabled, will remove the two casts. But, if the value were a column, > the double casts would exist in the plan sent to the, resulting in an > unnecessary extra step. > The expected behavior is the function argument type propagation would not > insert a cast if it is not needed. > Researching a bit more, it seems this is an artifact of recent changes in > {{toSql()}}. In the {{NumericLiteral}}, we always display the type as a cast. > The query specified a cast also, so the outer cast comes from the original > SQL, the inner from pushing the cast type into the numeric literal. > This is not so much a bug as it is a muddling of the semantics. There is no > reason to push the type into the numeric literal if an explicit cast exists. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org