Re: Calling variadic function with default value in named notation

Wolfgang Walther <walther(at)technowledgy(dot)de> writes:
> 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?

Looking back at the original discussion about named arguments,

https://www.postgresql.org/message-id/flat/15635.1249842629%40sss.pgh.pa.us

there was quite extensive discussion about how they should interact
with VARIADIC, and we ended up settling on the current behavior,
which is that you must explicitly say VARIADIC if you want a
named-arguments call to match a variadic function. The argument
for requiring that was basically to avoid confusion, which I think
is reasonable.

Now what I don't see in that thread is any mention of the possibility of
allowing the variadic parameter to be defaulted --- which is problematic
with this rule mostly because then there's noplace to write VARIADIC.

Still, the fact that this hasn't come up in ten-plus years says
that it's a pretty niche use case. I'm not sure that it's worth
doing anything about.

I did poke at the code a little bit, and the fact that the function isn't
matched just comes down to these two lines in FuncnameGetCandidates:

if (OidIsValid(procform->provariadic) && expand_variadic)
continue;

If you delete them then all these cases work, but so would some other
ones that I doubt we should allow. I'd be inclined to insist that
the only two cases we should allow are (1) the variadic parameter
isn't listed in the call (so it's defaulted), or (2) it is listed
with an explicit VARIADIC marker (which is the case we allow now).

regards, tom lane