You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Marieke Gueye (Jira)" <ji...@apache.org> on 2021/04/06 23:16:00 UTC

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

    [ 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:15 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)
```
Should just be `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)