[CALCITE-828] Use RelBuilder in rules rather than type-specific RelNode factories

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.5.0
• Assignee: Julian Hyde
• Reporter: Julian Hyde
• Created: 03/Aug/15 21:47
• Updated: 27/Feb/24 22:24
• Resolved: 28/Sep/15 20:33

Description

Many planner rules create filters, projects, joins, ... and over the years people have made them generic, so they can create different particular sub-classes of RelNodes (say DrillFilter or HiveProject) by adding factories (interfaces defined in RelFactories).

But then people extend a rule, so that a rule that used to only create projects now might sometimes create a filter. They now need to add an extra parameter to the instance of the rule, which is painful. Also, rules may call into utility methods such as RelOptUtil.pushDownJoinConditions (see CALCITE-826), which have similar problems.

The solution is to get rid of factories in public interfaces and instead pass around a RelBuilder. A particular instance of RelBuilder has a factory inside it for each type of RelNode. In general a particular client of Calcite (e.g. Hive) will be able to use the same RelBuilder throughout a query.

Rules are static, so a rule instance cannot contain a RelBuilder, only a ProtoRelBuilder, which can create a RelBuilder given a RelOptCluster and RelOptSchema.

Issue Links

• breaks: CALCITE-948 Indicator columns not preserved by RelFieldTrimmer
• is depended upon by: CALCITE-856 Make more rules extensible
• is related to: CALCITE-826 Use ProjectFactory in AggregateJoinTranposeRule and FilterJoinRule