[
https://issues.apache.org/jira/browse/CALCITE-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900506#comment-17900506
]
Mihai Budiu commented on CALCITE-6702:
--------------------------------------
Let me reproduce some comments I left on the PR:
The Strong class is used during optimizations.
The JavaDoc for Strong says "Utilities for strong predicates."
However, POWER is not a predicate.
So I don't know whether this change has any effect.
It is not easy to audit all the places where Strong is used in the codebase to
determine whether it will have any effect on any program. Most places I could
find only simplify predicates.
I don't know if this has any effect on the *_REDUCE_EXPRESSIONS set of
optimization rules, where perhaps POWER with a constant null argument could be
simplified to NULL at compile-time.
Do you have an example which is affected by this issue?
BTW: there is another class NullPolicy which seems to overlap in functionality
with Strong. That class is used during code-generation for the Enum interpreter.
The only place where the Policy is actually used is in RexSimplify, where it is
used to check whether some expressions are always null. So perhaps you can can
write a SqlToRelConverter test that checks to see whether the call to
POWER(null, x) is replaced in the program with a constant NULL.
Since Strong provides only a conservative approximation, AS_IS is not wrong, it
may be just a missed optimization opportunity.
> Strong Policy for the `SqlStdOperatorTable.POWER` is wrongly assigned `AS_IS`
> when it should be `ANY`
> -----------------------------------------------------------------------------------------------------
>
> Key: CALCITE-6702
> URL: https://issues.apache.org/jira/browse/CALCITE-6702
> Project: Calcite
> Issue Type: Bug
> Reporter: Dhia Eddine Nini
> Assignee: Dhia Eddine Nini
> Priority: Major
> Labels: pull-request-available
> Attachments: image-2024-11-20-17-14-28-261.png,
> image-2024-11-22-12-45-23-068.png
>
>
> +Context:+
> In standard SQL (such as MySQL and PostgreSQL), running the following queries:
> {code:java}
> SELECT POWER(NULL, 2) AS "ALIAS1";
> SELECT POWER(2, NULL) AS "ALIAS2";{code}
> Returns for both queries:
> {code:java}
> NULL
> {code}
> This means that the proper null policy for the expression is `ANY` instead of
> `AS_IS`, since this expression is null {*}if and only if at least one of its
> arguments is null{*}.
> !image-2024-11-20-17-14-28-261.png!
> The `SqlKind` of the the POWER function is `SqlKind.OTHER_FUNCTION`
> The fix should be relatively simple.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
