[
https://issues.apache.org/jira/browse/CALCITE-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16254394#comment-16254394
]
Jesus Camacho Rodriguez edited comment on CALCITE-2041 at 11/15/17 11:01 PM:
-----------------------------------------------------------------------------
bq. Potentially this could cause the whole expression to change type from
nullable to not null. So if the type of the whole expression needs to be
preserved (think project expressions) compensating casts will need to be added
at the top.
In fact this flag will only be 'false' (i.e. do not match nullability) on the
Hive side for the Filter instance of ReduceExpressionsRule. Setting the flag to
'false' for the Project instance of the rule would potentially cause issues
with the planner, as the nullability of an expression row type generated by a
rule needs to be equal to the one of the expression that was matched by the
rule (we talked about this in another issue).
was (Author: jcamachorodriguez):
bq. Potentially this could cause the whole expression to change type from
nullable to not null. So if the type of the whole expression needs to be
preserved (think project expressions) compensating casts will need to be added
at the top.
In fact this flag will only be 'false' (i.e. do not match nullability) on the
Hive side for the Filter instance of ReduceExpressionsRule. Setting the flag to
'false' for the Project instance of the rule would potentially cause issues
with the planner, as the nullability of an expression row type generated by a
rule needs to match the one of the expression that was matched by the rule (we
talked about this in another issue).
> Adding the ability to turn off nullability matching for ReduceExpressionsRule
> -----------------------------------------------------------------------------
>
> Key: CALCITE-2041
> URL: https://issues.apache.org/jira/browse/CALCITE-2041
> Project: Calcite
> Issue Type: Bug
> Reporter: slim bouguerra
> Assignee: Julian Hyde
> Fix For: 1.15.0
>
>
> In some cases, the user needs to select whether or not to add casts that
> match nullability.
> One of the motivations behind this is to avoid unnecessary casts like the
> following example.
> original filter
> {code}
> OR(AND(>=($0, CAST(_UTF-16LE'2010-01-01 00:00:00
> UTC'):TIMESTAMP_WITH_LOCAL_TIME_ZONE(15)), <=($0, CAST(_UTF-16LE'2012-03-01
> 00:00:00 UTC'):TIMESTAMP_WITH_LOCAL_TIME_ZONE(15))))
> {code}
> the optimized expression with matching nullability
> {code}
> OR(AND(CAST(>=($0, 2010-01-01 00:00:00)):BOOLEAN, CAST(<=($0, 2012-03-01
> 00:00:00)):BOOLEAN))
> {code}
> As you can see this extra cast gets into the way of following plan
> optimization steps.
> The desired expression can be obtained by turning off the nullability
> matching.
> {code}
> OR(AND(>=($0, 2010-01-01 00:00:00), <=($0, 2012-03-01 00:00:00)))
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
