[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 81.90%. Comparing base (8fe5a1a) to head (01e8b71).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2484      +/-   ##
==========================================
+ Coverage   81.84%   81.90%   +0.05%     
==========================================
  Files          42       42              
  Lines       34667    34764      +97     
  Branches    34667    34764      +97     
==========================================
+ Hits        28373    28472      +99     
+ Misses       2753     2752       -1     
+ Partials     3541     3540       -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.