fix(expr): array_length and cardinality returns int32 as in PostgreSQL

[xiangjinwu]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Since this commit, the frontend will generate plans with int32.

For backward compatibility, the backend will run both int32 and int64 variants as requested by the query plan.

Note: Having both cardinality(list) -> int32 and cardinality(list) -> int64 in the function signature map means the type inferring logic cannot find a unique match. But we have them covered in infer_type_for_special to always return int32. Eventually it is still better to clean them up from the function signature map.

Checklist For Contributors

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have demonstrated that backward compatibility is not broken by breaking changes and created issues to track deprecated features to be removed in the future. (Please refer to the issue)
• All checks passed in ./risedev check (or alias, ./risedev c)

Documentation

Types of user-facing changes

• SQL commands, functions, and operators

Release note

array_length and cardinality returns int32 as in PostgreSQL

[xiangjinwu]

This variant is just added by #10197 and we do not need to worry about backward compatibly.

[codecov]

Codecov Report

Merging #10267 (8177f86) into main (981b40e) will increase coverage by 0.00%.
The diff coverage is 88.76%.

@@           Coverage Diff           @@
##             main   #10267   +/-   ##
=======================================
  Coverage   70.58%   70.59%           
=======================================
  Files        1245     1245           
  Lines      212653   212733   +80     
=======================================
+ Hits       150096   150169   +73     
- Misses      62557    62564    +7     

Flag	Coverage Δ
rust	70.59% <88.76%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/frontend/src/expr/type_inference/func.rs	80.91% <0.00%> (ø)
src/expr/src/vector_op/cardinality.rs	22.22% <25.00%> (-2.78%)	⬇️
src/expr/src/vector_op/array_length.rs	16.66% <60.00%> (+3.62%)	⬆️
src/expr/src/sig/func.rs	89.38% <100.00%> (+22.71%)	⬆️

... and 4 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[xxchan]

Eventually it is still better to clean them up from the function signature map.

Do you have any plan or idea about how to clean it?

[xxchan]

I listed the non-unique signatures in a test.

[xiangjinwu]

Eventually it is still better to clean them up from the function signature map.

Do you have any plan or idea about how to clean it?

#10285