[
https://issues.apache.org/jira/browse/CALCITE-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15997863#comment-15997863
]
Rajeshbabu Chintaguntla commented on CALCITE-1306:
--------------------------------------------------
[~julianhyde] Thanks for modifications. Now rebased my branch to
1306-group-alias and updated the pull request.
bq. I think "select deptno as dno from emp group by cube(1)" should be valid
in the default conformance (because you can cube by expressions).
This might be big change so as discussed yesterday we can raise another JIRA
for this and work separately.
> Allow GROUP BY and HAVING to reference SELECT expressions by ordinal and alias
> ------------------------------------------------------------------------------
>
> Key: CALCITE-1306
> URL: https://issues.apache.org/jira/browse/CALCITE-1306
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Rajeshbabu Chintaguntla
> Labels: dialect, phoenix
>
> Allow GROUP BY and HAVING to reference SELECT expressions by ordinal and
> alias. It is not standard SQL, but MySQL and PostgreSQL allow it.
> See [Stack Overflow: SQL - using alias in Group
> By|http://stackoverflow.com/questions/3841295/sql-using-alias-in-group-by].
> It would be enabled only by new methods {{isGroupByOrdinal}} and
> {{isGroupByAlias}} in SqlConformance.
> We might allow alias in the HAVING clause (as described in HIVE-10557) but
> ordinal does not make sense.
> Expressions that are not available before grouping would be illegal; for
> instance:
> {code}
> select count(*) as c
> from t
> group by c
> {code}
> We'd also need rules to resolve ambiguous expressions. For instance, in
> {code}
> select e.empno as deptno
> from emp as e join dept as d
> where e.deptno = d.deptno
> group by deptno
> {code}
> does {{deptno}} refer to {{e.deptno}}, {{d.deptno}}, or {{e.empno}}?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
