Re: Calling variadic function with default value in named notation

Tom Lane:
> 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 looked at this a lot longer than on my latest endeavor in boolean
algebra [somewhere else] and came to the conclusion that the only other
case that would be allowed by this change is in the following:

create function f(x int, variadic y int[] default '{}')
returns void language sql as '';

-- was ok before
select f(x=>1, variadic y=>'{2}');

-- ability to default is the goal
select f(x=>1);

-- omitting the variadic keyword is now also possible
select f(x=>1, y=>'{2}');

So for mixed/named notation the variadic keyword would now be optional.
I realize that this has been discussed intensively in the thread you
mentioned - but did I miss any other cases that are now allowed as well?

> 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.

Thanks for the link! I read through the whole thread and this is what I
took from it:
The reasons for making the variadic keyword required in named notation
calls are (1) to keep backwards compatibility for future extensions -
the only one that comes to mind is repeating named arguments for the
variadic elements as mentioned by me somwhere upthread - and (2) to
avoid confusion.

There were no extensions in that regard in the last ten-plus years, so I
would assume it was safe to make this keyword optional now. I don't see
repeated named arguments coming up anytime. I didn't hear of any
language allowing this, yet, and tried googling for it but didn't come
up with any as well. I'm most likely wrong here, but it doesn't seem
widespread at least.

As for the confusion... I'm very much convinced that any confusion on
this topic is from lack of documentation. I guess we agree on that. If
making named calls with a variadic keyword was documented more, it
should be easily possible to state it as optional as well. That should
avoid any confusion.

> 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.

Well, I tried to use it that way, so my opinion is different ;)

Since the question of how to call functions in positional/mixed/named
notations seems to be pretty much settled, it would make sense to just
"finish" this and allow defaulting the variadic named keyword. It's
strange to be allowed to set a default and not be able to use it once
you name any argument.

If the optional variadic keyword is indeed the only thing that changes
when removing those two lines, I think this would fix the default case
without much effort. The documentation improvement seems neccessary in
any case.

Of course the next thing you tell me will be that I missed 10 other
cases that are implied by this change as well and everything I wrote is
rendered void... ;)

Best

Wolfgang