feat(frontend): support single dimension array for extended-mode query

[jetjinser]

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

What's changed and what's your intention?

Split e2e_test/batch/types/array_ty.slt.part into 1-dim e2e_test/batch/types/array_1d_ty.slt.part and multi-dim (keep original name).

Partially resolved - #7949.

import psycopg

def ep(query):
    cur.execute(query, binary=True)  # type: ignore
    for row in cur:
        print(row)
    print()

conn = psycopg.connect(host="localhost", port="4566", dbname="dev", user="root")
with conn.cursor() as cur:
    int_tys = ["int2", "int4", "int8", "rw_int256", "numeric"]
    flt_tys = ["float4", "float8"]
    txt_tys = ["text", "bytea"]

    for it in int_tys:
        query = f"select Array[1::{it}, 2::{it}, 3::{it}]"
        ep(query)

    for ft in flt_tys:
        query = f"select Array[1.1::{ft}, 2.2::{ft}, 3.3::{ft}]"
        ep(query)

    for tt in txt_tys:
        query = f"select Array['a'::{tt}, 'b'::{tt}, 'c'::{tt}]"
        ep(query)

    # error: n-dim where n > 1
    # query = "select Array[Array[1, 2, 3], Array[4, 5, 6]]"
    # ep(query)

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added test labels as necessary. See details.
• 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

If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

[neverchanje]

Thanks @xiangjinwu PTAL

[xiangjinwu]

Make sure only 1 dimension?

[jetjinser]

https://docs.rs/postgres-types/0.2.6/postgres_types/trait.ToSql.html#arrays

risingwave/src/common/src/types/to_binary.rs

Lines 124 to 127 in 855cd7d

	DataType::Struct(_) | DataType::List(_) => bail_not_implemented!(
	issue = 7949,
	"the pgwire extended-mode encoding for lists with more than one dimension ({ty}) is unsupported"
	),

I think it should be guaranteed here that there will only be an array of 1 dimension?

[xiangjinwu]

But as a general trait implementation, to_sql may have other callers (in the future) in addition to to_binary.

[jetjinser]

I rechecked, the postgres-types checked the array dimensions, so it was handled correctly:
https://github.com/sfackler/rust-postgres/blob/e528e01bbe2f7e198a55112fd6de3a24db3b8a6e/postgres-types/src/lib.rs#L586-L588

If the array dimension is greater than 1, it will return Err with error message.

[neverchanje]

The current implementation looks fine to me. I don't see buggy points.

[xiangjinwu]

The link above is for FromSql. There seems to be no check of multiple dimensions in ToSql there:
https://github.com/sfackler/rust-postgres/blob/e528e01bbe2f7e198a55112fd6de3a24db3b8a6e/postgres-types/src/lib.rs#L960

Can we confirm by actually executing to_sql on a Vec<Vec<i32>> or ListRef of ListRef of i32 value?

[neverchanje]

Does it mean that INT[] can be accpeted by DATE[]?
You should check the inner type as well.

[jetjinser]

I don't think accept has a way to check the inner type... it only know the postgres_type::Type.
It should be a limitation of the ToSql api.

[xiangjinwu]

I don't think accept has a way to check the inner type... it only know the postgres_type::Type. It should be a limitation of the ToSql api.

What's _ inside the postgres_types::Kind::Array(_) then?

[jetjinser]

Oh I understand, but we can still only check whether ty is a one-dimensional array. Is this implementation correct?

[github-actions]

This PR has been open for 60 days with no activity. Could you please update the status? Feel free to ping a reviewer if you are waiting for review.