Re: Calling variadic function with default value in named notation

út 3. 11. 2020 v 21:04 odesílatel Wolfgang Walther <walther(at)technowledgy(dot)de>
napsal:

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

I dislike the proposed change. The using VARIADIC keyword is signal so
arguments are used in different than usual format. More, it introduces
other inconsistency between named and unnamed notation. So it may remove
one issue, but introduces another issue.

Regards

Pavel

> Best
>
> Wolfgang
>
>
>