[ 
https://issues.apache.org/jira/browse/IGNITE-18931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-18931:
--------------------------------------
    Description: 
Currently expressions like "expr() = expr()" and "expr() != expr()" for 
non-deterministic functions (for example rand_uuid()) do not work correctly.

The problem seems to be related to the optimization made in 
RexProgramBuilder#registerInternal, ignoring the fact that the function is 
non-deterministic.

{code:java}
final RexSimplify simplify =
        new RexSimplify(rexBuilder, RelOptPredicateList.EMPTY, 
RexUtil.EXECUTOR);
    expr = simplify.simplifyPreservingType(expr);
{code}

This optimization translates comparison
{{<>($t1, $t1)}}
to 
{{CAST(AND(null, IS NULL($t1))):BOOLEAN NOT NULL}}

And it looks like a naive fix would be to apply this optimization only if 
{{RexUtil.isDeterministic(rexNode)}} returns true.

{{RexProgramBuilder}} currently is not a part of Ignite-3 codebase and it seems 
that it will be better to do such fix in Apache Calcite.

However, before doing this, we need to learn the discussions that have been 
made on this topic previously.

CALCITE-2823
https://issues.apache.org/jira/browse/CALCITE-3760
https://issues.apache.org/jira/browse/CALCITE-2142
https://issues.apache.org/jira/browse/CALCITE-2638
https://issues.apache.org/jira/browse/CALCITE-3531
https://issues.apache.org/jira/browse/CALCITE-4256

  was:
Currently expressions like "expr() = expr()" and "expr() != expr()" for 
non-deterministic functions (for example rand_uuid()) do not work correctly.

The problem seems to be related to the optimization made in 
RexProgramBuilder#registerInternal, ignoring the fact that the function is 
non-deterministic.

{code:java}
final RexSimplify simplify =
        new RexSimplify(rexBuilder, RelOptPredicateList.EMPTY, 
RexUtil.EXECUTOR);
    expr = simplify.simplifyPreservingType(expr);
{code}

This optimization translates comparison
{{<>($t1, $t1)}}
to 
{{CAST(AND(null, IS NULL($t1))):BOOLEAN NOT NULL}}

And it looks like a naive fix would be to apply this optimization only if 
{{RexUtil.isDeterministic(rexNode)}} returns true.

{{RexProgramBuilder}} currently is not a part of Ignite-3 codebase and it seems 
that it will be better to do such fix in Apache Calcite.

However, before doing this, we need to learn the discussions that have been 
made on this topic previously.

https://issues.apache.org/jira/browse/CALCITE-2823
https://issues.apache.org/jira/browse/CALCITE-3760
https://issues.apache.org/jira/browse/CALCITE-2142
https://issues.apache.org/jira/browse/CALCITE-2638
https://issues.apache.org/jira/browse/CALCITE-3531
https://issues.apache.org/jira/browse/CALCITE-4256


> Sql. Invalid expression code generation for comparing the results of a 
> non-deterministic function.
> --------------------------------------------------------------------------------------------------
>
>                 Key: IGNITE-18931
>                 URL: https://issues.apache.org/jira/browse/IGNITE-18931
>             Project: Ignite
>          Issue Type: Improvement
>          Components: sql
>            Reporter: Pavel Pereslegin
>            Priority: Major
>              Labels: ignite-3
>
> Currently expressions like "expr() = expr()" and "expr() != expr()" for 
> non-deterministic functions (for example rand_uuid()) do not work correctly.
> The problem seems to be related to the optimization made in 
> RexProgramBuilder#registerInternal, ignoring the fact that the function is 
> non-deterministic.
> {code:java}
> final RexSimplify simplify =
>         new RexSimplify(rexBuilder, RelOptPredicateList.EMPTY, 
> RexUtil.EXECUTOR);
>     expr = simplify.simplifyPreservingType(expr);
> {code}
> This optimization translates comparison
> {{<>($t1, $t1)}}
> to 
> {{CAST(AND(null, IS NULL($t1))):BOOLEAN NOT NULL}}
> And it looks like a naive fix would be to apply this optimization only if 
> {{RexUtil.isDeterministic(rexNode)}} returns true.
> {{RexProgramBuilder}} currently is not a part of Ignite-3 codebase and it 
> seems that it will be better to do such fix in Apache Calcite.
> However, before doing this, we need to learn the discussions that have been 
> made on this topic previously.
> CALCITE-2823
> https://issues.apache.org/jira/browse/CALCITE-3760
> https://issues.apache.org/jira/browse/CALCITE-2142
> https://issues.apache.org/jira/browse/CALCITE-2638
> https://issues.apache.org/jira/browse/CALCITE-3531
> https://issues.apache.org/jira/browse/CALCITE-4256



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to