feat(expr): implement array_flatten

[stdrc]

Many query engines/databases have builtin function array_flatten or flatten to flatten an array of arrays. And it is also requested by our user. This PR adds it for RisingWave.

For the sake of simplicity and clarity, we implement this function following Snowflake, Trino, DuckDB, which means, this function works in a non-recursive way, only flattening one level of nesting.

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

Checklist

• I have written necessary rustdoc comments.
• I have added necessary unit tests and integration tests.
• I have added test labels as necessary.
• I have added fuzzing tests or opened an issue to track them.
• My PR contains breaking changes.
• My PR changes performance-critical code, so I will run (micro) benchmarks and present the results.
• I have checked the Release Timeline and Currently Supported Versions to determine which release branches I need to cherry-pick this PR into.

Documentation

• My PR needs documentation updates.

Release note

[stdrc]

• refactor(common): rename DataType::as_list to as_list_element_type #21643
• feat(expr): implement array_flatten #21640 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[Copilot]

Pull Request Overview

This PR implements an array_flatten function for RisingWave, adding native support for flattening one level of nesting in arrays. The key changes include:

• Updating optimizer and expression visitors to handle ARRAY_FLATTEN.
• Adding a new builtin scalar function in the binder for array_flatten.
• Implementing the array_flatten logic in a new scalar module and updating type handling and proto definitions accordingly.

Reviewed Changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/frontend/src/optimizer/plan_expr_visitor/strong.rs	Added ARRAY_FLATTEN support in the strong visitor.
src/frontend/src/expr/pure.rs	Added ARRAY_FLATTEN into the impure analyzer’s type list.
src/frontend/src/binder/expr/function/builtin_scalar.rs	Introduced the array_flatten function with appropriate type checks and error messages.
src/expr/impl/src/scalar/mod.rs	Included the new array_flatten module.
src/expr/impl/src/scalar/array_flatten.rs	New implementation for array_flatten following Snowflake/DuckDB behavior.
src/common/src/types/mod.rs	Added a new conversion method into_list_element_type for type consistency.
proto/expr.proto	Extended the enum to include ARRAY_FLATTEN.

Comments suppressed due to low confidence (1)

src/common/src/types/mod.rs:513

• Consider renaming the 'as_list' method or updating its usage so that the naming is consistent with 'into_list_element_type' elsewhere in the code, which would improve clarity for the list element extraction methods.

/// TODO(rc): rename to `as_list_element_type`

[github-actions]

Hi, there.

📝 Telemetry Reminder:
If you're implementing this feature, please consider adding telemetry metrics to track its usage. This helps us understand how the feature is being used and improve it further.
You can find the function report_event of telemetry reporting in the following files. Feel free to ask questions if you need any guidance!

• src/frontend/src/telemetry.rs
• src/meta/src/telemetry.rs
• src/stream/src/telemetry.rs
• src/storage/compactor/src/telemetry.rs
  Or calling report_event_common (src/common/telemetry_event/src/lib.rs) as if finding it hard to implement.
  ✨ Thank you for your contribution to RisingWave! ✨

---

This is an automated comment created by the peaceiris/actions-label-commenter. Responding to the bot or mentioning it won't have any effect.

[BugenZhao]

LGTM

[xiangjinwu]

Just realized array_flatten(arr) is equivalent to genuine_array_concat(VARIADIC arr). However:

• This hypothetical genuine_array_concat is different from PostgreSQL/RisingWave array_cat, which has a wired behavior on >= 2d array due to its weak array typing (int[][] is same as int[])
• #14753 implements VARIADIC as separate exprs but in PostgreSQL there is a single concat_ws / jsonb_extract_path

Just sharing some related ideas. Nothing to change in this PR.