You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Yu Xu (Jira)" <ji...@apache.org> on 2026/06/23 03:40:00 UTC
[jira] [Created] (CALCITE-7620) Result of FILTER clause in window functions is incorrect
Yu Xu created CALCITE-7620:
------------------------------
Summary: 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
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)