From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Wolfgang Walther <walther(at)technowledgy(dot)de> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Calling variadic function with default value in named notation |
Date: | 2020-10-28 21:18:19 |
Message-ID: | 1449498.1603919899@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Wolfgang Walther <walther(at)technowledgy(dot)de> writes:
> create function b(x int, variadic y int[] default '{}')
> returns void language sql as '';
> select b(x=>1, variadic y=>'{2}');
> [ ok ]
> select b(x=>1);
> ERROR: function b(x => integer) does not exist
> I could not find anything in the documentation that points this out as a
> limitation, so I expected this to work. Did I miss anything?
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.
Perhaps a better error message could be wished for, but given the
current rules this can't succeed.
One could imagine saying that if the function has a variadic last
parameter, then we can match that to zero or more positional arguments
after the last named argument. Not sure that that would be a good
idea though, or how hard it'd be to implement. It'd be a pretty
radical departure from the rules for non-variadic functions.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2020-10-28 21:34:51 | Re: Calling variadic function with default value in named notation |
Previous Message | Wolfgang Walther | 2020-10-28 21:02:02 | Calling variadic function with default value in named notation |