To summarise the discussion so far the various problems reported by Vladimir have two root causes:
1) the rule operands which might be in different conventions; 2) the rule transformation which might be in different convention than the input expression. I would suggest to try to find a solution for the above before bringing in the discussion more elements. @Vladimir: Is there something more that we shall consider at the same time? Here is a quick suggestion without a lot of thinking. We could add a new method in RelOptRule#getConventionMatcher (or getTraitMatcher or a better name) which returns a matcher (enumeration?) describing how the rule should handle cases 1 and 2 above. It returns an appropriate value by default. Then either in RelOptRule#matches or just before calling matches we examine the operands and act accordingly (solves problem 1). Finally, in call#transformTo we also consider the value of this method and either throw an exception or turn the transform to a NOOP (solves problem 2). How does it look? Best, Stamatis Στις Παρ, 1 Φεβ 2019 στις 11:23 μ.μ., ο/η Vladimir Sitnikov < [email protected]> έγραψε: > > . For rules tagged as “single-convention”, we could add some support in > the engine to reduce the burden on the person writing the rule > The issue is current rules are broken, and it would be nice to fix > that without having to rewrite each and every rule. > > > >categorize rules as “converters” > > It makes sense to categorize rel classes as well. > For instance, LogicalProject'a input should always be Convention.NONE. > Then Calcite could raise an error when > LogicalProject(EnumerableFilter(..)) is created. > > Vladimir >
