Bug

Parser::parse_comment parses the argument list for COMMENT ON FUNCTION / PROCEDURE / AGGREGATE using bare parse_data_type. PostgreSQL permits an argmode (IN / OUT / INOUT / VARIADIC) and an argname before the type — they are ignored for identity resolution, but they appear in real-world pg_dump output and in consumer-authored schema files. With the bare parse_data_type reader, all of these hard-fail today:

COMMENT ON FUNCTION add(a int, b int) IS '...';                   -- argname
COMMENT ON FUNCTION upsert(IN id int, OUT result text) IS '...';  -- modes
COMMENT ON FUNCTION concat_all(VARIADIC arr text[]) IS '...';     -- VARIADIC

Fix

Swap parse_data_type for parse_function_arg in the FUNCTION / PROCEDURE / AGGREGATE arms of parse_comment. parse_function_arg already consumes [mode] [name] type [DEFAULT expr]. Statement::Comment.arguments is Option<Vec<DataType>>, so we project with .into_iter().map(|a| a.data_type).collect() — the mode/name are intentionally discarded since they are not part of the function identity for COMMENT ON. Round-trip canonicalises to the bare-type form, matching the existing serializer.

No other call sites of parse_data_type are touched.

Tests

Added to tests/sqlparser_postgres.rs:

• parse_comment_on_function_with_argname — add(a INTEGER, b INTEGER) round-trips to bare types
• parse_comment_on_function_with_argmode — IN/OUT/INOUT modes
• parse_comment_on_function_with_variadic — VARIADIC arr TEXT[]
• parse_comment_on_aggregate_with_argname_and_variadic — same shapes for COMMENT ON AGGREGATE

Downstream

Unblocks pgmold's COMMENT ON AST migration, which currently rejects valid Postgres dumps containing these shapes.

Verification

Locally green:

• cargo fmt --all
• cargo clippy --all-targets --all-features -- -D warnings
• cargo test --all-features
• cargo check --no-default-features --target thumbv6m-none-eabi
• (cd sqlparser_bench && cargo clippy --all-targets --all-features -- -D warnings)