[IMPALA-7845] Clarify Impala's policy for use of column aliases

• Type: Bug
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: Impala 3.0
• Component/s: Frontend
• Epic Color: ghx-label-3
• Assignee: Unassigned
• Reporter: Paul Rogers
• Created: 13/Nov/18 19:27
• Updated: 01/Mar/19 18:15

Description

Column aliases can allow users to provide a name to an expression within the SELECT clause:

SELECT (id + int_col) / 3 AS c
FROM ...

There is considerable variation about how SQL implementations allow aliases to be used. Impala's rules appear to be:

• GROUP BY and ORDER BY can reference aliases, but not within expressions.
• HAVING attempts to allow aliases, but fails to do so due to bugs.

The general rule is that the analyzer will recognize aliases as long as the alias is the only node in an expression. For example:

ORDER BY c -- c can be an alias or column
ORDER BY c + 2 -- c must be a table column, not an alias

As a result of the above rule, alias are not supported in the HAVING clause, since HAVING is an expression (like WHERE) not a list (like GROUP BY and ORDER BY.)

However, Impala tries to support aliases in HAVING:

        havingPred_ = substituteOrdinalOrAlias(havingClause_, "HAVING", analyzer_);

Again, this does not work because the top-level node must be a Boolean operator (such as =), it will never be an alias.

This ticket asks to clearly define Impala's intent for the use of aliases, then adjust the analyzer code to implement this decision.

References:

• MySQL supports aliases in HAVING.
• MySQL supports aliases in WHERE
• SQLServer supports alias in GROUP BY
• SQLServer does not support alias in WHERE
• PostgreSql supports aliases in ORDER BY, but not in WHERE, HAVING or GROUP BY.

Issue Links

• relates to: IMPALA-5191 Behavior of GROUP BY, HAVING, ORDER BY with column aliases should be more standard conforming