[
https://issues.apache.org/jira/browse/CALCITE-7620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-7620:
------------------------------------
Labels: pull-request-available (was: )
> Result of FILTER clause in window functions is incorrect
> --------------------------------------------------------
>
> Key: CALCITE-7620
> URL: https://issues.apache.org/jira/browse/CALCITE-7620
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.42.0
> Reporter: Yu Xu
> Assignee: Yu Xu
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.43.0
>
>
> This is a follow-up jira of https://issues.apache.org/jira/browse/CALCITE-7595
> As discussion, the result is not right. According to my investigation, the
> main reason is:
> # *The FILTER clause was not actually applied.* Although the syntax was
> supported, the filter argument was not propagated through {{RexOver}} →
> {{Window.RexWinAggCall}} → {{{}AggregateCall{}}}. Specifically,
> {{Window.Group.getAggregateCalls}} hard-coded {{{}filterArg = -1{}}}, so
> {{EnumerableWindow.implementAdd}} always received a {{null}} filter and
> aggregated all rows regardless of the {{FILTER (WHERE ...)}} condition.
> # *The result ordering was wrong because the top-level {{ORDER BY}} Sort was
> incorrectly removed.* The window operator's collation metadata advertised
> only the window {{ORDER BY}} keys, ignoring the {{PARTITION BY}} grouping.
> This made the planner believe the window output was already globally sorted
> by {{{}empno{}}}, so it eliminated the required top-level sort, while
> {{EnumerableWindow}} actually emits rows grouped by partition key.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
