[
https://issues.apache.org/jira/browse/CALCITE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16258131#comment-16258131
]
Julian Hyde commented on CALCITE-2051:
--------------------------------------
By "semantics" I mean what the SQL statement returns to the end user, not from
the perspective of the Hive developer. As you point out, the bits returned by
{{GROUPING__ID}} function will change, because it is driven by the {{GROUP BY}}
clause. But other than that, paring down the GROUP BY clause has no effect on
semantics.
Do you acknowledge that it was a mistake for Hive to diverge from the standard
and have a dual GROUP BY and GROUPING SETS clause?
I can work with you on lowering the impact on Hive developers, but I want to
establish that developer convenience it what is at issue here, not loss of
expressive power.
> Rules using Aggregate might check for simple grouping sets incorrectly
> ----------------------------------------------------------------------
>
> Key: CALCITE-2051
> URL: https://issues.apache.org/jira/browse/CALCITE-2051
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Jesus Camacho Rodriguez
> Assignee: Jesus Camacho Rodriguez
> Priority: Critical
> Fix For: 1.15.0
>
>
> CALCITE-1069 removed the indicator columns for Aggregate operators. In some
> places, the indicator boolean check was replaced by the following check:
> {{aggregate.getGroupSets().size() > 1}}. However, that check is incomplete,
> it should have been replaced by {{aggregate.getGroupType() != Group.SIMPLE}}.
> For instance :
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/AggregateProjectMergeRule.java#L91
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
