[LucaCappelletti94]

PostgreSqlDialect could not parse the VARIADIC argument marker in a function call, in any position:

Parser::parse_sql(&PostgreSqlDialect {}, "SELECT concat(VARIADIC a)");
// Err: sql parser error: Expected: ), found: a at Line: 1, Column: 24

The marker is added as FunctionArg::Variadic. Parsing is gated on Dialect::supports_variadic_function_argument, enabled for PostgreSQL and the generic dialect.

As in PostgreSQL, the marker is rejected on a wildcard operand, in combination with DISTINCT or ALL, and on any but the final argument.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.33%. Comparing base (49033b0) to head (3f68d03).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2484      +/-   ##
==========================================
+ Coverage   82.29%   82.33%   +0.04%     
==========================================
  Files          42       42              
  Lines       35315    35396      +81     
  Branches    35315    35396      +81     
==========================================
+ Hits        29061    29143      +82     
  Misses       2695     2695              
+ Partials     3559     3558       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sabir-akhadov-localstack]

One non-blocking comment inline.

[sabir-akhadov-localstack]

This span starts at the operand, so for SELECT f(VARIADIC a, b) the "must be the last function argument" error points at a rather than at VARIADIC; capturing the keyword's span (or using self.peek_token_ref().span.start in the position check) would put it on the marker.

[LucaCappelletti94]

Fixed it, but span really is a mess of its own and we'll have to handle it some time after the tokenizer refactoring. Thanks for pointing this one out.