[
https://issues.apache.org/jira/browse/CALCITE-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799154#comment-16799154
]
Ruben Quesada Lopez commented on CALCITE-2941:
----------------------------------------------
Sure, I'll add a test as soon as I can.
> EnumerableLimitRule on Sort with no collation creates EnumerableLimit with
> wrong traitSet and cluster
> -----------------------------------------------------------------------------------------------------
>
> Key: CALCITE-2941
> URL: https://issues.apache.org/jira/browse/CALCITE-2941
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.18.0
> Reporter: Ruben Quesada Lopez
> Assignee: Ruben Quesada Lopez
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> EnumerableLimitRule _"converst a Sort that has offset or fetch set to an
> EnumerableLimit on top of a 'pure' Sort that has no offset or fetch"_. This
> is the "normal" scenario, and there is no issue with that.
> However, there is another scenario, where the EnumerableLimitRule is applied
> on an "empty" Sort (with no field collations) with offset / fetch. In that
> case, the EnumerableLimit's input will not be the Sort (because it will
> disappear, since it was empty), but the Sort's input. The problem comes in
> this case, because the EnumerableLimit will be created with the Sort's
> traitSet and cluster; instead of the Sort's input (which is the actual
> EnumerableLimit input) traitSet and cluster.
> Probably the bug can be easily fixed by using EnumerableLimit#create method,
> instead of EnumerableLimit's constructor.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
