[
https://issues.apache.org/jira/browse/IMPALA-7844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17342224#comment-17342224
]
ASF subversion and git services commented on IMPALA-7844:
---------------------------------------------------------
Commit ff52064823695e0cfffc9c9df3e7a1487f7b570a in impala's branch
refs/heads/master from stiga-huang
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=ff52064 ]
IMPALA-7844: Default to not allow ordinals in HAVING clause
Base on the discussion of the previous patch, we decide to not allow
ordinals in the HAVING clause since 4.0. It's a non-standard feature
that unintentionally supported by Impala 3.x and earlier versions.
This patch disables it by default, and add a feature flag to turn it on
for users that do depend on it.
Tests:
- Modify existing FE tests to test on the flag.
- Add custom cluster test to verify the flag works.
Change-Id: I0a57b8b65b046fae483e485e8391f8222fa586a5
Reviewed-on: http://gerrit.cloudera.org:8080/17415
Reviewed-by: Zoltan Borok-Nagy <[email protected]>
Tested-by: Impala Public Jenkins <[email protected]>
> Analysis code incorrectly attempts to support ordinals in HAVING clause
> -----------------------------------------------------------------------
>
> Key: IMPALA-7844
> URL: https://issues.apache.org/jira/browse/IMPALA-7844
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
> Affects Versions: Impala 3.0
> Reporter: Paul Rogers
> Assignee: Quanlong Huang
> Priority: Blocker
>
> SQL defines the idea of ordinals, which is, apparently, an old way to specify
> columns in the {{ORDER BY}} and {{GROUP BY}} clauses:
> {code:sql}
> SELECT int_col, id
> FROM functional.alltypestiny
> GROUP BY 1
> ORDER BY 2
> {code}
> The use of an ordinal is semi-ambiguous (is it an ordinal or a literal), but
> DBs (including Impala) usually interpret a single integer as an ordinal, but
> interpret any expression as a constant. (For example, {{1}} is an ordinal,
> but {{2 - 1}} is the constant value 1.)
> The use of ordinals works because {{ORDER BY}} and {{GROUP BY}} are lists: it
> is clear when an integer stands alone as an ordinal.
> The {{HAVING}} (and {{WHERE}}) clauses are expressions. For this reason, DB's
> do not support ordinals in these clauses. For example, what is the meaning
> below:
> {code:sql}
> SELECT int_col, id
> FROM functional.alltypestiny
> WHERE 1 = 2
> {code}
> Does this mean that the first column equals 2? That the second column equals
> 1? The first and second columns are equal? That the constant 1 equals the
> constant 2?
> To avoid such ambiguity, neither the SQL standard nor any implementations
> support ordinals in the {{HAVING}} (or {{WHERE}}) clauses.
> Yet, [Impala attempts to do
> so|https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/SelectStmt.java#L549]:
> {code:java}
> havingPred_ = substituteOrdinalOrAlias(havingClause_, "HAVING",
> analyzer_);
> {code}
> This ticket proposes to remove this code to make it clear that the {{HAVING}}
> clause cannot contain an ordinal.
> References:
> * [Redshift HAVING
> clause|https://docs.aws.amazon.com/redshift/latest/dg/r_HAVING_clause.html]
> * [Impala
> docs|https://impala.apache.org/docs/build3x/html/topics/impala_having.html]
> are silent on this question.
> * [SQL Standard BNF for
> HAVING|https://jakewheat.github.io/sql-overview/sql-2011-foundation-grammar.html#_7_10_having_clause]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
