Tom Lane:
> You can't write positional arguments after named arguments, so the
> failure to match isn't all that surprising; that is, to accept this
> call we'd have to interpret it as a named argument and then an empty
> list of things to match positionally to the variadic parameter.
It's not possible to have positional after named arguments and variadic
arguments always come last. Therefore, once any other argument is named
(so the call is made with either named or mixed notation) any variadic
argument will always have to be named. In this case it could be
interpreted as a named argument, even if absent, so the default value
should be given.
The information about the call being in named or mixed notation should
be available well in advance, when the statement is parsed. Do you think
it would be possible to "expect a named variadic argument" and then
fallback to the default in this case?
David G. Johnston:
> I too failed to realize that there was an implied, required,
> positional, parameter, of cardinality zero, following the named parameter.
IMHO it's neither required nor positional. Not required, because it has
a default value and not positional because it can never be in this case
(see above).
> I see no reason to make that case work. I'm doubtful additional words
> in the documentation, examples or otherwise, would have helped people
> commit this edge case to memory. The error message would be of
> benefit but IMO it isn't worth the effort given the sparsity of
> complaints and the assumed rarity that all three of these dynamics
> come into play in order to have an obscure doesn't work scenario.
One reason for the lack of complaints so far could also be, that people
don't realize it's actually possible to call variadic arguments in named
notation at all. This fact is not at all obvious from the documentation,
it's spread across different places.
In general, although PG doesn't implement it that way, variadic
arguments don't have to be unnamed by nature. Something like the
following could be very much imaginable:
SELECT func(a => 1, b => 2, a => 3, a => 4)
PG chooses to implement calling variadic arguments in named notation
with array syntax + variadic keyword. PG also implements DEFAULT values
for variadic arguments (something that could have been done differently
as well!). It would just make sense to support both together as well.
Best regards
Wolfgang