sql: render PostgreSQL array literals as ARRAY[...] in unparser

[xiedeyantu]

Which issue does this PR close?

• Closes #.

Rationale for this change

PostgreSQL array literals should be rendered using ARRAY[...] syntax when unparsing SQL. Without this, roundtripped PostgreSQL SQL can lose the dialect-specific array form and emit a plain bracketed array literal instead.

What changes are included in this PR?

• Added a dialect hook to indicate whether array literals should render as ARRAY[...].
• Enabled that behavior for PostgreSqlDialect.
• Updated the SQL unparser to honor the dialect setting when rendering array expressions.
• Adjusted the PostgreSQL roundtrip test to expect ARRAY[1, 2, 3, 4, 5].

Are these changes tested?

Yes. The PostgreSQL roundtrip test in plan_to_sql.rs covers the array literal case and verifies the unparsed SQL now uses ARRAY[...].

Are there any user-facing changes?

Yes. PostgreSQL SQL generated by DataFusion will now emit array literals in ARRAY[...] form instead of plain bracketed form.

[xiedeyantu]

@metegenez Could you please help me review this PR?

[metegenez]

Sure, tomorrow I'll look at it

[metegenez]

Nice change, this looks correct to me. One request before approving: could you add a test that exercises the second code path you modified?

The current test SELECT [1, 2, 3, 4, 5] only hits the make_array scalar function branch (around line 604). The other hunk you changed (around line 615, the ScalarValue::List branch) isn't covered, since the literal stays as a make_array call through the roundtrip and never reaches that code.

A small unit test that builds an Expr::Literal(ScalarValue::List(...)) directly and calls expr_to_sql under PostgreSqlDialect, asserting the output is ARRAY[1, 2, 3], would pin that line down. A nested case like [[1, 2], [3, 4]] → ARRAY[ARRAY[1, 2], ARRAY[3, 4]] would also be a nice sanity check that recursion through the hook works as expected.

Otherwise LGTM.

[xiedeyantu]

Nice change, this looks correct to me. One request before approving: could you add a test that exercises the second code path you modified?

The current test SELECT [1, 2, 3, 4, 5] only hits the make_array scalar function branch (around line 604). The other hunk you changed (around line 615, the ScalarValue::List branch) isn't covered, since the literal stays as a make_array call through the roundtrip and never reaches that code.

A small unit test that builds an Expr::Literal(ScalarValue::List(...)) directly and calls expr_to_sql under PostgreSqlDialect, asserting the output is ARRAY[1, 2, 3], would pin that line down. A nested case like [[1, 2], [3, 4]] → ARRAY[ARRAY[1, 2], ARRAY[3, 4]] would also be a nice sanity check that recursion through the hook works as expected.

Otherwise LGTM.

I have added 2 cases based on your comments. Please take a look.

[metegenez]

Thanks for the effort. LGTM.

[xiedeyantu]

@metegenez Hi, could we merge this PR?

[xiedeyantu]

@metegenez Thanks for your review!