>1) the rule operands which might be in different conventions That is the most common problem.
> 2) the rule transformation which might be in different convention than the > input expression. If #1 is solved, then #2 is more or less solved automatically. Note: transforming a relation to a different convention is NOT bad. It works just fine. The offending behavior is #3: 3) the rule creates invalid rel hierarchies. For instance, a rule should not create LogicalFilter(EnumerableProject(...)) kind of expression trees. To a certain degree, it is "solved" by placing assertions in the relevant constructors that validate that "input has NONE convention". However, those assertions are not enforced, so bad rules exist. I think we could cover lots of cases by placing asserts in LogicalProject, LogicalFilter, etc constructors. Stamatis >We could add a new method in RelOptRule#getConventionMatcher (or Stamatis > getTraitMatcher or a better name) which returns a matcher (enumeration?) That basically forces to rewrite all the existing rules which is sad, that is why I look for options that would not require to rewrite existing code. Stamatis >Then either in RelOptRule#matches or just Stamatis > before calling matches we examine the operands and act accordingly The problem is we want planner to be aware of the match policy. For instance, currently it uses Map<Class,...> to select the set of possible rules. If you go with "before calling matches" then it is a bit too late. Vladimir
