[
https://issues.apache.org/jira/browse/CALCITE-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15995467#comment-15995467
]
Julian Hyde commented on CALCITE-1306:
--------------------------------------
Very nice work, [~rajeshbabu]. I re-organized and extended a little and pushed
to https://github.com/julianhyde/calcite/tree/1306-group-alias. Only one very
minor quibble: 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). Can
you fix that and we're done.
> 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)
