[ 
https://issues.apache.org/jira/browse/CALCITE-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16734083#comment-16734083
 ] 

Vladimir Sitnikov commented on CALCITE-2648:
--------------------------------------------

In the mean time, I've fired tests for a conservative approach: 
[https://github.com/apache/calcite/pull/992]

Conservative approach is to assume LogicalWindow and Project (with OVER) have 
empty collation.

> Output collation of EnumerableWindow is not consistent with its implementation
> ------------------------------------------------------------------------------
>
>                 Key: CALCITE-2648
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2648
>             Project: Calcite
>          Issue Type: Bug
>    Affects Versions: 1.17.0
>            Reporter: Hongze Zhang
>            Assignee: Julian Hyde
>            Priority: Major
>
> Here is a case:
> {code:sql}
> select x, COUNT(*) OVER (PARTITION BY x) from (values (20), (35)) as t(x) 
> ORDER BY x
> {code}
> Final plan:
> {code:java}
> EnumerableWindow(window#0=[window(partition {0} order by [] range between 
> UNBOUNDED PRECEDING and UNBOUNDED FOLLOWING aggs [COUNT()])])
>   EnumerableValues(tuples=[[{ 20 }, { 35 }]])
> {code}
> Output rows:
> {code:java}
> X  |EXPR$1 |
> ---|-------|
> 35 |1      |
> 20 |1      |
> {code}
> EnumerableWindow is supposed to preserve input collations, as a result 
> EnumerableSort is ignored. However the implementation of EnumerableWindow 
> generates non-ordered output (when PARTITION BY clause is used).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to