[jira] [Comment Edited] (CALCITE-4094) Allow SqlOperator of SqlKind#OTHER_FUNCTION to define a Strong.Policy

["Stamatis Zampetakis (Jira)" <ji...@apache.org>]

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

Stamatis Zampetakis edited comment on CALCITE-4094 at 6/30/20, 10:14 PM:
-------------------------------------------------------------------------

Not necessarily something that we should discuss here but maybe we should consider unifying {{Strong.Policy}} and {{NullPolicy}} and make it available through the {{SqlOperator}}. We use {{Strong.Policy}} mostly on the simplifier  and {{NullPolicy}} on the code generator but do we need to have two abstractions? Also it seems that this information is useful to be part of the operator definition isn't it?

We can open a new jira if you think its worth pursuing this direction.


was (Author: zabetak):
Not necessarily something that we should discuss here but maybe we should consider unifying {{Strong.Policy}} and {{NullPolicy}} and make it available through the {{SqlOperator}}. We use {{Strong.Policy}} mostly on the simplifier  and {{NullPolicy}} on the code generator but do we need to have two abstractions? Also it seems that this information is useful to be part of the opearator definition isn't it?

We can open a new jira if you think its worth pursuing this direction.

> 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
>
>
> {{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)