[CALCITE-4559] Create 'interface RexRule', a modular rewrite for row-expressions

• Type: Bug
• Status: In Progress
• Priority: Major
• Resolution: Unresolved
• Assignee: Julian Hyde
• Reporter: Julian Hyde
• Created: 30/Mar/21 02:09
• Updated: 30/Jul/21 19:40

Description

We propose to add class RexRule, a rewrite rule for row-expressions (class RexNode).

class RexRule is analogous to how class RelRule (and the older class RelOptRule) operates on relational expressions (interface RelNode). Also, class RexRuleProgram is analogous to HepProgram and VolcanoPlanner (it indexes rules so that we do not have to try every rule against every part of the expression). And a rule describes which operands it matches using RexRule.describe(RexRule.OperandBuilder), similar to calling RelRule.Config.operandSupplier().apply().

The advantages of RexRule are similar to RelRule: rules can be defined in a modular way, can be documented and tested individually, and can be enabled individually.

The rules could be applied in various ways. RelBuilder.Config could contain a RexRuleProgram that would be applied every time an expression is simplified by a RelBuilder. There could also be a sub-class of interface RelShuttle that applies the rules to every RexNode in a tree (e.g. inside Filter, Project and Join).

I don't yet know whether, or how, rules might support 3-valued boolean logic (RexUnknownAs). For example, a rule that simplifies "x = x" to "TRUE" is valid in an "unknownAsFalse" context (e.g. as top-level of Filter condition), but not in an "unknownAsUnknown" context (e.g. in Project expression).

This case is related to CALCITE-3470 (making relational and row-expression rules more similar, as in CockroachDB), but would deliver an API rather than a textual DSL.

Issue Links

• relates to: CALCITE-4711 RexProgramBuilder should not simplify
• relates to: CALCITE-3470 Add a RelOptRule-based text DSL
• relates to: CALCITE-2449 RexSimplify overhaul