[
https://issues.apache.org/jira/browse/CALCITE-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963910#comment-15963910
]
radu commented on CALCITE-1740:
-------------------------------
[~julianhyde]
I get the point your argument. The reason why i was thinking to have the
distinct flag carried by the aggregate was because you can have within the same
group by/select/over different aggregates among which only some have distinct.
Also the OVER window for which i am considering this does not accept the
DISTINCT as an option to eliminate duplicates before applying the functions.
Nevertheless, going with the proposal you made - the problem as i see it is
that the AggregateCall object is only created when you call the get function -
when is it instantiated directly with false for distinct. There is not
particular object that can carry the distinct flag until that point because the
project object and then the window object after the ProjectToWindowRule only
carry the aggregate functions.
> Distinct aggregate flag in window function
> ------------------------------------------
>
> Key: CALCITE-1740
> URL: https://issues.apache.org/jira/browse/CALCITE-1740
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: radu
> Assignee: Julian Hyde
> Labels: build, windows
>
> When parsing queries such as
> SELECT B1, SUM(DISTINCT B2) OVER (ORDER BY B4 RANGE BETWEEN INTERVAL '10'
> SECOND PRECEDING AND CURRENT ROW) FROM T
> The aggregates in the LogicalWindow do not have any marker of being distinct.
> isDistinct() flag is not set. Probably some rule(s) silently swallow the
> DISTINCT keyword
> The LogicalWindow object that result is
> LogicalWindow(window#0=[window(partition {} order by [2] range between $3
> PRECEDING and CURRENT ROW aggs [COUNT($1), $SUM0($1)])])
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
