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)