[
https://issues.apache.org/jira/browse/CALCITE-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315881#comment-17315881
]
Marieke Gueye edited comment on CALCITE-4559 at 4/6/21, 11:17 PM:
------------------------------------------------------------------
Hey Julian,
Here are some examples of rules I had in mind:
*Double cast*
_dt_ being of Data Type Date
{{CAST(CAST(dt as TIMESTAMP) AS DATE)}}
{{Or}}
{{DATE(CAST(dt as TIMESTAMP)}}
{{=> dt}}
Same with other data types
*Time Zone method Optimizations*
For some dialects like BigQuery Standard SQL, multiple methods accept timezones
as inputs
(In BQ FORMAT_TIMESTAMP, EXTRACT from timestamp, and TIMESTAMP_TRUNC)
In that case, we have
_ts_ being of Data Type Timestamp
{{DateOp(TzConvert(ts, fromTz, toTz), misc1, misc2)}}
{{ => DateWithTzOp(ts, misc1, misc2, fromTz, toTz)}}
*Time diff optimization*
_ts1_ and _ts2_ being timestamp, datetime ..
_fromTz_ and _toTz_ two timezones
{{TIME_DIFF(HOUR , TzConvert(ts1, fromTz, toTz), TzConvert(ts2, fromTz, toTz))}}
{{=> TIME_DIFF(HOUR , ts1, ts2 )}}
was (Author: mkou):
Hey Julian,
Here are some examples of rules I had in mind:
*Double cast*
_dt_ being of Data Type Date
{{CAST(CAST(dt as TIMESTAMP) AS DATE)}}
{{Or}}
{{DATE(CAST(dt as TIMESTAMP)}}
{{=> dt}}
Same with other data types
*Time Zone method Optimizations*
For some dialects like BigQuery Standard SQL, multiple methods accept timezones
as inputs
(In BQ FORMAT_TIMESTAMP, EXTRACT from timestamp, and TIMESTAMP_TRUNC)
In that case, we have
_ts_ being of Data Type Timestamp
{{{{DateOp(TzConvert(ts, fromTz, toTz), misc1, misc2)}}}}
{{ => DateWithTzOp(ts, misc1, misc2, fromTz, toTz)}}
*Time diff optimization*
_ts1_ and _ts2_ being timestamp, datetime ..
_fromTz_ and _toTz_ two timezones
{{TIME_DIFF(HOUR , TzConvert(ts1, fromTz, toTz), TzConvert(ts2, fromTz, toTz))}}
{{=> TIME_DIFF(HOUR , ts1, ts2 )}}
> 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)
