[ 
https://issues.apache.org/jira/browse/CALCITE-4094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17149800#comment-17149800
 ] 

Danny Chen edited comment on CALCITE-4094 at 7/2/20, 4:10 AM:
--------------------------------------------------------------

I was thinking of adding an interface in SqlFunction, something like 
SqlFunction#getStrongPolicy and give it a default value.

Is there any strong reason we must deprecate policy(SqlKind) ?

If we add an interface SqlFunction#getStrongPolicy, the only exception is the 
SqlKind.OTHER_FUNCTION, when we encounter that, a SqlFunction instance should 
be passed in.

For the other SqlKind and policy mapping, it is great if we can make the 
mapping configurable and pluggable, just like what we do to SqlTypeMappingRule.


was (Author: danny0405):
I was thinking of adding an interface in SqlFunction, something like 
SqlFunction#getStrongPolicy and give it a default value.

Is there any strong reason we must deprecate this interface ?

If we add an interface SqlFunction#getStrongPolicy, the only exception is the 
SqlKind.OTHER_FUNCTION, when we encounter that, a SqlFunction instance should 
be passed in.

For the other SqlKind and policy mapping, it is great if we can make the 
mapping configurable and pluggable, just like what we do to SqlTypeMappingRule.

> Allow SqlOperator of SqlKind#OTHER_FUNCTION to define a Strong.Policy
> ---------------------------------------------------------------------
>
>                 Key: CALCITE-4094
>                 URL: https://issues.apache.org/jira/browse/CALCITE-4094
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>            Reporter: Ruben Q L
>            Assignee: Ruben Q L
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.24.0
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{FilterJoinRule}} performs some optimizations based on 
> {{RelOptUtil#simplifyJoin}}. Specifically, this part of the code:
> {code}
> if (joinType.generatesNullsOnRight()
>   && Strong.isNotTrue(filter, rightBitmap)) {
>     joinType = joinType.cancelNullsOnRight();
> }
> {code}
> allows e.g. a LEFT join with a condition on its RHS to be transformed into an 
> INNER join, with the condition pushed on its right input.
> In order to achieve this, the utility class {{Strong}} defines a certain 
> {{Policy}} map, depending on the {{SqlKind}} of a {{RexNode}} (i.e. depending 
> on the filter condition). In case of operators such as {{EQUALS}}, 
> {{NOT_EQUALS}}, {{LESS_THAN}}, etc, it defines {{Policy.ANY}} (i.e. 
> expression is null if and only if at least one of its arguments is null). In 
> case of a left join with conditions with this policy on the right-hand-side, 
> the join gets simplified by this module because of the nullability of the 
> right columns. However, in the case of {{SqlUserDefinedFunction}} the policy 
> is the default {{Policy.AS_IS}}, which prevents the simplification from 
> happening.
> It is proposed to enrich {{SqlUserDefinedFunction}} with an optional 
> {{Strong.Policy}}, and adapt {{Strong}} code so that these functions can also 
> benefit from this simplification.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to