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