As the number of rules grows, it becomes more difficult to find out whether a similar rule has already been added. The fact that there are several ways to name a rule adds to the confusion.
For instance, consider a rule that converts ‘join(project(x), project(y))’ into ‘project(join(x, y))’. The actual rule is called PullUpProjectsAboveJoinRule but it could equally be called PushJoinThroughProjectsRule. There are lots of rules called PushXxxThroughYyyRule, too. I propose the naming convention <Reltype1><Reltype2>[…]<Verb>Rule, where ReltypeN is the class of the Nth RelNode matched, in depth-first order, ignoring unimportant operands, and removing any ‘Rel’ suffix Verb is what happens — typically Transpose, Swap, Merge, Optimize. Thus: PullUpProjectsAboveJoinRule becomes JoinProjectTransposeRule PushAggregateThroughUnionRule becomes AggregateUnionTransposeRule MergeProjectRule becomes ProjectMergeRule MergeFilterOntoCalcRule becomes FilterCalcMergeRule EnumerableJoinRule remains EnumerableJoinRule (Or how about JoinAsEnumerableRule?) SwapJoinRule becomes JoinSwapInputsRule I’d like to hear what people think of these names. What happens if you apply this naming convention to rules you have created? If there is consensus that this is an improvement, let’s rename the existing rules as part of https://issues.apache.org/jira/browse/OPTIQ-296. The naming convention would of course be optional. Rule authors would not need to follow it if they don’t feel that it makes things clearer. Julian
