[CALCITE-5332] Configuring PruneEmptyRules is cumbersome

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.32.0
• Fix Version/s: 1.33.0
• Component/s: core
• Labels: pull-request-available
• Assignee: Stamatis Zampetakis
• Reporter: Stamatis Zampetakis
• Created: 13/Oct/22 11:09
• Updated: 07/Feb/23 22:33
• Resolved: 28/Nov/22 15:23

Description

After CALCITE-4787/CALCITE-4839 (release 1.28.0) it is pretty complicated to create new PruneEmptyRule instances with slightly different configurations.

The most common use-case is to modify a rule, for instance PruneEmptyProject, and change the operands to enlarge or restrict the matching scope; e.g., instead of matching the general Project.class match only HiveProject.class.

At the moment this task is not straightforward for various reasons.

We cannot create the new rule by obtaining the configuration from the existing instance (e.g., PROJECT_INSTANCE) cause the latter is declared as RelOptRule. Unless we cast the instance to RelRule we cannot get access to its configuration and change it.

ImmutableRemoveEmptySingleRuleConfig is package private as every other immutable class so again we cannot start from there.

The constructors of RemoveEmptySingleRule are either deprecated or package private so cannot/should not be used.

RemoveEmptySingleRuleConfig does not provide a DEFAULT configuration instance.

The only way "recommended" way to create a new rule instance at the moment is to implement the respective config interface. This is unnecessary and requires quite a bit of work if the consumer is not using the immutables library annotation processor.

Issue Links

• is caused by: CALCITE-4787 Move core to use Immutables instead of ImmutableBeans
• is caused by: CALCITE-4839 Remove remnants of ImmutableBeans post 1.28 release
• links to: GitHub Pull Request #2937