[
https://issues.apache.org/jira/browse/CALCITE-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798320#comment-16798320
]
Julian Hyde commented on CALCITE-2941:
--------------------------------------
Looks good (I'm glad that you switched to using the {{create}} method - using
constructors for RelNodes is an anti-pattern), but can you include a test case?
> 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
> 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)
