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

["Julian Hyde (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CALCITE-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julian Hyde updated CALCITE-4559:
---------------------------------
    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.

  was:
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.

I am working on a prototype that illustrates the key interfaces and demonstrates a couple of rules and tests for them.


> 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)