[CALCITE-7592] Add expression support for FETCH

[tkalkirill]

Jira Link

CALCITE-7592

Changes Proposed

This PR introduces support for arithmetic and scalar expressions for "FETCH", enabling queries to execute similarly to those in other popular DBMSs (PostgreSQL, Oracle, H2, and MS SQL):

SELECT * FROM person FETCH NEXT (? + 1) ROWS ONLY;
SELECT * FROM person FETCH NEXT (udf(?)) ROWS ONLY;
SELECT * FROM person FETCH NEXT (1 + NVL(?, 10000)) ROWS ONLY.

[xuzifu666]

Please refer to other PR and modify the title accordingly. Also, please fix the CI bug to facilitate future reviews. @tkalkirill

[xiedeyantu]

Could you add some test cases to your Quidem test and compare the results with those from pgsql (e.g., using https://onecompiler.com/postgresql)?

[tkalkirill]

@xuzifu666 I think I've fixed everything.
@xiedeyantu Added "fetch.iq" and compared it with (https://onecompiler.com/postgresql); it matches.

Could one of you take a look at the PR, or do you have any recommendations on who I should send it to for review?

[xiedeyantu]

This PR does touch quite a few files. I took a quick look through it, and the tests seem good overall. I've left some comments for now—could you take a look?

[xiedeyantu]

I see many checks for whether parameters are dynamic. Is it possible to converge to a single utility method?

[tkalkirill]

Good point. There are two identical recursive checks for dynamic parameters. I will move this logic to RexUtil.containsDynamicParam and reuse it.
The remaining instanceof RexDynamicParam checks are intentionally local because they distinguish a dynamic parameter as the root node from a parameter nested inside an expression, so replacing all of them with one predicate would change their semantics.

The remaining checks have different semantics: some detect a root dynamic parameter, while others search recursively or decide whether an expression can be evaluated during planning. Converging all of them would require a broader API and changes outside the scope of CALCITE-7592. I suggest keeping those checks explicit and considering a broader cleanup separately.

[xiedeyantu]

Will it support ? + abs(2) and fetch next (select 2) or fetch next (select max(col)) from t)?

[xuzifu666]

I also have questions about this; perhaps should add some details on how to address this.

[tkalkirill]

Sorry for the delayed reply; I was away on a short vacation.

I tested the queries in the current implementation:

select * from person fetch next (? + abs(2)) rows only; --will **work**.
select * from person fetch next ? + abs(2) rows only; --will **fail** with a parsing error.
--
select * from person fetch next (select 2) rows only; --will **fail** with a parsing error.
select * from person fetch next (select ?) rows only; --will **fail** with a parsing error.
select * from person fetch next (select max(id) from peson) rows only; --will **fail** with a parsing error.

I tested queries containing SELECT subqueries in Postgres, and they all executed successfully. In my current change, I proposed supporting only arithmetic operations and scalar expressions—excluding subqueries, even scalar ones.

I suggest adding support for them as a separate task later on, should the need arise.

I am currently adding tests for the aforementioned queries.

@xiedeyantu @xuzifu666 What do you think?

[sonarqubecloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
80.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[xiedeyantu]

In Calcite, the LIMIT and OFFSET values ​​are not restricted to the LONG type; they can be arbitrarily large. As this link, we will use BigDecimal. Is the restriction to the long type here due to issues with Enumerable execution? The int above has the same issue.