[
https://issues.apache.org/jira/browse/CALCITE-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17325311#comment-17325311
]
Julian Hyde commented on CALCITE-4559:
--------------------------------------
{quote}I would suggest defining a public pattern interface that allows for
user-defined implementations.{quote}
We did this in {{RelRule}} initially, and it didn't turn out well.
{{RelOptRuleOperand}} was a public class with a protected constructor, so it
was possible to sub-class it. People would create their own sub-classes of
operands (sometimes anonymous) and change behavior by overriding the {{boolean
matches(RelNode)}} method. We wanted to create modified copies of trees of
operands, but because they were sub-classes we were not able to copy them.
The solution was to make operands pure data. (If you wanted to override
behavior, you provide lambdas. These can easily be plugged into the copies.)
I suppose we could have had 'data classes' (final, immutable) but we would then
have had to copy them into the actual data structure that we use at run time
(which has links from parents to children and children to parents). Instead, we
have a "builder API" that the people who define rules will call in order to
build the operand data structure. I have followed the same pattern for this
proposal.
> Create 'interface RexRule', a modular rewrite for row-expressions
> -----------------------------------------------------------------
>
> Key: CALCITE-4559
> URL: https://issues.apache.org/jira/browse/CALCITE-4559
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
> Priority: Major
>
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
