feat(expr): Implement lambda function and array_transform

[TennyZhuang]

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

What's changed and what's your intention?

Resolve #11952

• Bind lambda function
• Implement array_transform

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
• All checks passed in ./risedev check (or alias, ./risedev c)
• My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

• My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

• My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

Implement array_transform

[xiangjinwu]

Ideas of some tests:

create table t(v int, arr int[]);

-- this makes sure `x + 1` is not extracted as common sub-expression by accident. See #11766
select array_transform(arr, |x| x + 1), array_transform(arr, |x| x + 1 + 2) from t;

-- this clarifies that we do not support referencing columns at this point
select array_transform(arr, |x| x + v) from t;

Also question on failure tolerance: if array_transform(array['2', 'a', '3'], |x| x::int) is used in a streaming query, do we expect it to return null::int[] or array[2, null, 3]? This may be out of the scope of this PR, but just want to bring this case to people's attention.

[codecov]

Codecov Report

Merging #11937 (995fbdd) into main (d1fe176) will decrease coverage by 0.06%.
The diff coverage is 5.04%.

@@            Coverage Diff             @@
##             main   #11937      +/-   ##
==========================================
- Coverage   70.21%   70.15%   -0.06%     
==========================================
  Files        1380     1382       +2     
  Lines      231054   231280     +226     
==========================================
+ Hits       162237   162263      +26     
- Misses      68817    69017     +200     

Flag	Coverage Δ
rust	70.15% <5.04%> (-0.06%)	⬇️

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

Files Changed	Coverage Δ
src/common/src/array/list_array.rs	85.03% <0.00%> (-2.42%)	⬇️
src/expr/src/expr/expr_array_transform.rs	0.00% <0.00%> (ø)
src/expr/src/expr/mod.rs	62.96% <ø> (ø)
src/frontend/src/binder/bind_context.rs	80.71% <ø> (ø)
src/frontend/src/binder/bind_param.rs	87.58% <0.00%> (-1.23%)	⬇️
src/frontend/src/expr/expr_mutator.rs	69.64% <0.00%> (-5.36%)	⬇️
src/frontend/src/expr/expr_rewriter.rs	48.21% <0.00%> (-4.73%)	⬇️
src/frontend/src/expr/expr_visitor.rs	83.54% <0.00%> (-4.46%)	⬇️
src/frontend/src/expr/function_call_with_lambda.rs	0.00% <0.00%> (ø)
src/frontend/src/expr/pure.rs	87.69% <ø> (ø)
... and 8 more

... and 7 files with indirect coverage changes

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

[chenzl25]

LGTM

[chenzl25]

Do we plan to support the lambda function capturing other input columns in the future? If yes, I am not sure whether this 0 index of InputRef would make it hard to be compatible in the future. Otherwise, It seems we need to introduce something like FunctionCallWithLambdaV2.

[TennyZhuang]

I guess we can use CorrelatedInputRef to represent the captured columns.

[chenzl25]

Not quite suitable I think, since we cannot evaluate CorrelatedInputRef in expressions directly. All CorrelatedInputRef need to be converted into InputRef during subquery unnesting.