You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@calcite.apache.org by GitBox <gi...@apache.org> on 2019/03/21 10:46:10 UTC

[GitHub] [calcite] rubenada opened a new pull request #1122: [CALCITE-2941] EnumerableLimitRule on Sort with no collation creates EnumerableLimit with wrong traitSet and cluster

rubenada opened a new pull request #1122: [CALCITE-2941] EnumerableLimitRule on Sort with no collation creates EnumerableLimit with wrong traitSet and cluster
URL: https://github.com/apache/calcite/pull/1122
 
 
   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.
   The bug can be easily fixed by using EnumerableLimit#create method, instead of EnumerableLimit's constructor.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services