[
https://issues.apache.org/jira/browse/CALCITE-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317322#comment-17317322
]
Julian Hyde commented on CALCITE-4559:
--------------------------------------
[~mkou], Thank you for adding those examples. They make perfect sense, and
illustrate what {{RexRule}} would be capable of.
The first example ("Double cast") would need a side-condition, to prevent us
from removing type conversions that are intentionally lossy. For example, if
{{x}} has type {{iNTEGER}}, then {{CAST(CAST(x AS TINYINT) AS BIGINT))}} cannot
be simplified to {{CAST(x AS BIGINT)}} because narrowing conversion to
{{TINYINT}} will have the effect of converting values into the range -256 ..
255. (There are similar narrowing conversions with decimal scale, converting
from floating point to fixed point, converting from fixed point to floating
point, string length, datetime and interval precision, and probably others. I'm
sure we can add the necessary smarts to Calcite's data types, and we can easily
make {{RexRule}} instances implement their own side-conditions.)
The third example ("Time diff optimization") could be parameterized on
timeUnit. Time unit (in this case {{HOUR}}) looks like a keyword in the SQL
syntax, but in Rex-land looks like a value. So we could perhaps have just one
instance of the rule, rather than requiring separate instances for HOUR,
MINUTE, MONTH etc.
> 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)
