[CALCITE-5861] Optimization rules do not constant-fold expressions in window bounds

[mihaibudiu]

With this change the PROJECT_REDUCE_EXPRESSIONS rule will also optimize constants that appear in window bound expressions. This makes it possible to compile programs that use (constant) expressions in window bounds.

However, I suspect that the rule PROJECT_TO_LOGICAL_PROJECT_AND_WINDOW is still buggy, since it will move window bound expressions into separate projections, as described in the JIRA case. Unfortunately I could not figure out how to fix that rule - the code is very generic and treats all expressions in the same way, regardless where they appear in the RexNode. Perhaps I should file another JIRA issue about this?

[mihaibudiu]

I would very much appreciate a review for this tiny PR.

[asolimando]

However, I suspect that the rule PROJECT_TO_LOGICAL_PROJECT_AND_WINDOW is still buggy, since it will move window bound expressions into separate projections, as described in the JIRA case. Unfortunately I could not figure out how to fix that rule - the code is very generic and treats all expressions in the same way, regardless where they appear in the RexNode. Perhaps I should file another JIRA issue about this?

I agree on separating the two problems and filing a separate Jira about moving the window bound expressions in a projection.

[asolimando]

@mihaibudiu, if you file a different ticket for the projection part, I guess the test you added will look different and involve only ReduceExpressionsRule, right?

In addition, in general, we tend to phrase the Jira ticket titles a bit differently though, something like "ReduceExpressionsRule rules should constant-fold expressions in window bounds", WDYT?

[mihaibudiu]

In the JIRA ticket discussion @julianhyde said this:

The SQL spec doesn't 'require' that bounds are constant. It says that a conforming implementation shall allow bounds that are constant. It doesn't say that a conforming implementation shall not allow bounds that are not constant.
If I recall correctly, Oracle allows expressions. It's a nice feature. We should continue to allow expressions, even if Postgres doesn't.

So I think based on this interpretation a second issue will not be necessary. I will rename the issue as you suggested.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

87.5% Coverage
0.0% Duplication

[NobiGo]

LGTM

[asolimando]

LGTM too

[mihaibudiu]

Maybe someone can merge this?