[
https://issues.apache.org/jira/browse/CALCITE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16257718#comment-16257718
]
Julian Hyde commented on CALCITE-2051:
--------------------------------------
bq. The operator could be more expressive than SQL
I do not believe so. In Hive, given "GROUP BY c1, c2, ... GROUPING SETS ((c11,
c12, ), (c21, c22, ...), ...)", AFAICT, you can always remove the "c1, c2, ..."
with no change in semantics.
When Hive calls Calcite to create an Aggregate with groupSet and groupSets
arguments, if groupSets is not null it is safe to assign groupSet =
ImmutableSet.union(groupSets) before calling. This is a straightforward change
and I doubt it would set back the release.
I'm sorry we didn't have the pre-condition in earlier. But because standard SQL
doesn't allow specifying both GROUP BY and GROUPING SETS, I never imagined
anyone would specify groupSet as anything other than the union of groupSets, as
there is no point in doing so.
> 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)
