Variadic parameters vs parameter defaults

Tom Lane <tgl@sss.pgh.pa.us> writes:

A related point is that, because the current code forbids a default
for a variadic, you can't do something like

create function foo (f1 int, f2 int default = 42, f3 variadic int[] = array[]::int[])

ie there's no way to have defaults on the preceding parameters either.
I don't know how useful that is, but maybe it's an argument for adopting
the second solution where you can explicitly specify a default for a
variadic.

Comments?

Well if you adopt the implicit empty array argument for missing variadic
parameters then you can just allow defaults for trailing parameters before the
final parameter.

I'm inclined to think an implicit empty array makes the most sense. If a
function-writer wants to enforce a minimum number of arguments they can check
and throw an error.

The question arises though whether it's useful to have any default other than
an empty array. I don't see a compelling reason.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!

Tom Lane wrote:

Oh, and another thing --- should variadic parameters be defaultable?
The current patch doesn't allow it but it looks more like an oversight
than anything that was thought through. The boundary case for variadic
parameters is a bit weird already:

From a user perspective, if we just told people "polymorphic and
variadic parameters do not accept defaults", and give people an error
message, I can't imagine anyone caring. Then we can support them
later if someone wants to troubleshoot the corner cases.

--Josh

Gregory Stark <stark@enterprisedb.com> writes:

I'm inclined to think an implicit empty array makes the most sense. If a
function-writer wants to enforce a minimum number of arguments they can check
and throw an error.

The question arises though whether it's useful to have any default other than
an empty array. I don't see a compelling reason.

I'm not sure if that's useful either. However, I think there are
probably quite a lot of cases where an empty array *isn't* desirable,
and so letting the current behavior alone seems okay, so long as there's
a way to override that and specify default = empty array when you do
want it to be possible.

The other way seems to boil down to "a variadic parameter has an
implicit default that you're not allowed to override", which doesn't
seem tremendously attractive.

regards, tom lane

On Wed, Dec 17, 2008 at 11:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

ISTM one could make a pretty good argument that this last case should
succeed, producing an empty-array argument. If you buy that, then it
is sensible to forbid defaults for variadics,

Yep, +1 for this approach. I would intuitively expect that, if I omit
variadic argument(s) when calling a function, that the function ends
up getting an empty array of the appropriate type.

And when writing a variadic function, I wouldn't find it all
surprising or annoying if I was not allowed to override this default.
In the unlikely case I want my function to do something special when
it gets an empty array, I can write that behaviour into the function
body.

Cheers,
BJ

"Brendan Jurd" <direvus@gmail.com> writes:

On Wed, Dec 17, 2008 at 11:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

ISTM one could make a pretty good argument that this last case should
succeed, producing an empty-array argument. If you buy that, then it
is sensible to forbid defaults for variadics,

Yep, +1 for this approach. I would intuitively expect that, if I omit
variadic argument(s) when calling a function, that the function ends
up getting an empty array of the appropriate type.

Actually, I just realized that there's another fly in the ointment:
the current variadic code allows "variadic anyarray", which is
equivalent to an appropriate number of anyelement arguments. If we
allow defaulting then there's a big problem: no principled way to
decide what type the empty array is.

The explicit-default solution would work around that, by making the
user say what type he wants. However it puts us right back into the
situation of having a default for a polymorphic argument, which I
was hoping to avoid.

regards, tom lane

On Wed, Dec 17, 2008 at 12:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Actually, I just realized that there's another fly in the ointment:
the current variadic code allows "variadic anyarray", which is
equivalent to an appropriate number of anyelement arguments. If we
allow defaulting then there's a big problem: no principled way to
decide what type the empty array is.

I see your point. Polymorphic + variadic is tricky.

Because Postgres cannot determine the "default" type for the empty
variadic anyarray argument, I think it makes sense to throw an error
in this case.

So if I had these two functions ...

var1(a int, b variadic int[])
var2(a int, b variadic anyarray)

... it would be okay to write var1(8), which resolves as var1(8,
array[]::int[]). But if I tried to write var2(8) I'd get an error.
Maybe something like "cannot determine type of missing variadic
arguments".

NB I have no idea whether such an approach would be practical to
implement, but I think it's the least astonishing set of behaviours.

Cheers,
BJ

"Brendan Jurd" <direvus@gmail.com> writes:

So if I had these two functions ...

var1(a int, b variadic int[])
var2(a int, b variadic anyarray)

... it would be okay to write var1(8), which resolves as var1(8,
array[]::int[]). But if I tried to write var2(8) I'd get an error.
Maybe something like "cannot determine type of missing variadic
arguments".

Well, we could unify these behaviors if we insisted on an explicit
default to omit the argument in both cases.

var1(a int, b variadic int[] default '{}'::int[])
var2(a int, b variadic anyarray default '{}'::text[]) -- perhaps

In both cases, supplying a single argument would be legal if and only
if you provided a default for the variadic parameter. As soon as you
give two arguments, the default isn't relevant anymore. This method
eliminates the discrepancy between anyarray and other types of variadic
parameters, and it leaves the door open for someone to use something
besides an empty array as the default. (Who are we to say that such a
thing is never useful? NULL seems like a possibly useful default for
instance.) I think it also makes the variadic and default features
a bit more orthogonal.

This still leaves us with the annoyance of having to prevent changes in
the actual datatype of a default associated with a polymorphic parameter;
but that's just some implementation tedium, and I'm beginning to find
it more attractive than the alternatives.

regards, tom lane

On Wednesday 17 December 2008 02:07:35 Tom Lane wrote:

Oh, and another thing --- should variadic parameters be defaultable?
The current patch doesn't allow it but it looks more like an oversight
than anything that was thought through. The boundary case for variadic
parameters is a bit weird already:

regression=# create function fv (f1 int, f2 variadic int[]) returns int
regression-# as 'select $1' language sql;
CREATE FUNCTION

regression=# select fv(1);
ERROR: function fv(integer) does not exist
LINE 1: select fv(1);
^
HINT: No function matches the given name and argument types. You might
need to add explicit type casts.

That looks like a bug to me. Anything that you can do with 1 to N items
should also work for zero.

Also, in C, variadic functions are quite commonly called with zero arguments
in the variadic position.

On Wednesday 17 December 2008 06:03:06 Tom Lane wrote:

"Brendan Jurd" <direvus@gmail.com> writes:

So if I had these two functions ...

var1(a int, b variadic int[])
var2(a int, b variadic anyarray)

... it would be okay to write var1(8), which resolves as var1(8,
array[]::int[]). But if I tried to write var2(8) I'd get an error.
Maybe something like "cannot determine type of missing variadic
arguments".

Well, we could unify these behaviors if we insisted on an explicit
default to omit the argument in both cases.

var1(a int, b variadic int[] default '{}'::int[])
var2(a int, b variadic anyarray default '{}'::text[]) -- perhaps

I would just pass an empty array if the type is clear and error out otherwise.
Mixing these things up makes things a lot more complicated for even normal
uses.

On Wednesday 17 December 2008 06:03:06 Tom Lane wrote:

This method
eliminates the discrepancy between anyarray and other types of variadic
parameters, and it leaves the door open for someone to use something
besides an empty array as the default.  (Who are we to say that such a
thing is never useful?

I think it is a mistake to consider this a default value issue at all. If you
pass zero arguments to a function, the function should get zero.

Or why would you pass <> N arguments when N are provided for any N?

2008/12/17 Peter Eisentraut <peter_e@gmx.net>:

On Wednesday 17 December 2008 02:07:35 Tom Lane wrote:

Oh, and another thing --- should variadic parameters be defaultable?
The current patch doesn't allow it but it looks more like an oversight
than anything that was thought through. The boundary case for variadic
parameters is a bit weird already:

regression=# create function fv (f1 int, f2 variadic int[]) returns int
regression-# as 'select $1' language sql;
CREATE FUNCTION

regression=# select fv(1);
ERROR: function fv(integer) does not exist
LINE 1: select fv(1);
^
HINT: No function matches the given name and argument types. You might
need to add explicit type casts.

That looks like a bug to me. Anything that you can do with 1 to N items
should also work for zero.

no, when we discused about variadic functions we defined, so variadic
parameter should not be empty Please, look to archive.

Pavel

"Pavel Stehule" <pavel.stehule@gmail.com> writes:

2008/12/17 Peter Eisentraut <peter_e@gmx.net>:

That looks like a bug to me. Anything that you can do with 1 to N items
should also work for zero.

no, when we discused about variadic functions we defined, so variadic
parameter should not be empty Please, look to archive.

Yeah, the problem is to infer a datatype when there are no actual
arguments to look at. If we wanted to drop "variadic anyarray" then
the corner case wouldn't be a problem, but that cure is worse than
the disease.

regards, tom lane

On Wed, 2008-12-17 at 19:43 +0200, Peter Eisentraut wrote:

That looks like a bug to me. Anything that you can do with 1 to N items
should also work for zero.

Previous discussion link:

http://archives.postgresql.org/pgsql-patches/2008-07/msg00149.php

You can make either mechanism do what you want by defining the right set
of functions. If a minimum of one argument per variadic parameter is
required, you can work around it by defining an extra function with no
variadic parameter to handle the zero-argument case.

So, although I agree with you, I don't have a strong opinion, and I'm
happy with either.

Regards,
Jeff Davis

On Tue, 2008-12-16 at 19:07 -0500, Tom Lane wrote:

regression=# select fv(1);
ERROR: function fv(integer) does not exist
LINE 1: select fv(1);
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.

ISTM one could make a pretty good argument that this last case should
succeed, producing an empty-array argument.

We had a similar discussion before, and you replied here:

http://archives.postgresql.org/pgsql-patches/2008-07/msg00150.php

Are you now in favor of allowing zero arguments for a variadic
parameter?

Regards,
Jeff Davis

Jeff Davis <pgsql@j-davis.com> writes:

Previous discussion link:
http://archives.postgresql.org/pgsql-patches/2008-07/msg00149.php

You can make either mechanism do what you want by defining the right set
of functions. If a minimum of one argument per variadic parameter is
required, you can work around it by defining an extra function with no
variadic parameter to handle the zero-argument case.

I think the bottom line here is that we need to make it possible for the
user to define what happens in the corner case. One of the problems
mentioned in the prior thread was that foo(variadic int[]) and
foo(variadic text[]) would conflict if it were possible to match both
to a zero-argument call. There's no principled solution to that if the
system insists on defining the behavior for zero args. However, with
the behavior I propose now, the user could determine which one is used
by giving a default to it and not the other one. That is,

foo(variadic int[] = array[]::int[])
foo(variadic text[])

causes the int[] one to get used for "foo()", and if you want the other
choice you hang the default on that one instead.

regards, tom lane

On Wednesday 17 December 2008 06:03:06 Tom Lane wrote:

and it leaves the door open for someone to use something
besides an empty array as the default.  (Who are we to say that such a
thing is never useful?  NULL seems like a possibly useful default for
instance.)

Another point against that: If you wanted something else besides an empty
array as "default", you can handle that inside the function body by just
looking at how many arguments were passed. Using the default mechanism
provides no added functionality.

Jeff Davis <pgsql@j-davis.com> writes:

On Tue, 2008-12-16 at 19:07 -0500, Tom Lane wrote:

ISTM one could make a pretty good argument that this last case should
succeed, producing an empty-array argument.

We had a similar discussion before, and you replied here:
http://archives.postgresql.org/pgsql-patches/2008-07/msg00150.php

Are you now in favor of allowing zero arguments for a variadic
parameter?

No, not as such (at least not now that I've had a chance to digest the
alternatives). The default-parameter mechanism gives us another
solution tool, but if you don't use a default then the same ambiguities
as before still exist.

regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:

Another point against that: If you wanted something else besides an empty
array as "default", you can handle that inside the function body by just
looking at how many arguments were passed. Using the default mechanism
provides no added functionality.

Well, the entire default mechanism provides "no additional
functionality", since you can always emulate it with a nest of functions
(or a single function that is able to accept a varying argument list and
look at how many arguments were passed; which, please note, is not
allowed in any of the existing PLs). What we're looking for here is a
convenient notational tradeoff. The behavior at zero arguments is
certainly a judgment call, but it seems to me that we'll wind up with
more warts and less flexibility if we try to make the system install a
default behavior for that case.

regards, tom lane

On Wednesday 17 December 2008 20:50:22 Tom Lane wrote:

The behavior at zero arguments is
certainly a judgment call, but it seems to me that we'll wind up with
more warts and less flexibility if we try to make the system install a
default behavior for that case.

Maybe we'll just let it be for now and see what kind of user demands we get.

Peter Eisentraut <peter_e@gmx.net> writes:

On Wednesday 17 December 2008 20:50:22 Tom Lane wrote:

The behavior at zero arguments is
certainly a judgment call, but it seems to me that we'll wind up with
more warts and less flexibility if we try to make the system install a
default behavior for that case.

Maybe we'll just let it be for now and see what kind of user demands we get.

Fair enough. We could possibly have the system install a "default
default" for variadic arguments, but I'd rather add that later
on the basis of demand than stick it in now.

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

Peter Eisentraut <peter_e@gmx.net> writes:

On Wednesday 17 December 2008 20:50:22 Tom Lane wrote:

The behavior at zero arguments is
certainly a judgment call, but it seems to me that we'll wind up with
more warts and less flexibility if we try to make the system install a
default behavior for that case.

Maybe we'll just let it be for now and see what kind of user demands we get.

Fair enough. We could possibly have the system install a "default
default" for variadic arguments, but I'd rather add that later
on the basis of demand than stick it in now.

My inclination would be to say zero arguments is zero arguments and you get a
zero-length array. We could eliminate the problem with anyelement by saying
the variadic argument can't be the only polymorphic argument.

I think there are going to be more users using non-polymorphic arguments who
are surprised that no arguments is a special case than people using
polymorphic arguments who are annoyed by restrictions at the intersection.

Actually I think my vote would be for whatever requires the least code now. If
you've already committed something then let's just go with that.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!

2008/12/17 Gregory Stark <stark@enterprisedb.com>:

Tom Lane <tgl@sss.pgh.pa.us> writes:

Peter Eisentraut <peter_e@gmx.net> writes:

On Wednesday 17 December 2008 20:50:22 Tom Lane wrote:

The behavior at zero arguments is
certainly a judgment call, but it seems to me that we'll wind up with
more warts and less flexibility if we try to make the system install a
default behavior for that case.

Maybe we'll just let it be for now and see what kind of user demands we get.

Fair enough. We could possibly have the system install a "default
default" for variadic arguments, but I'd rather add that later
on the basis of demand than stick it in now.

My inclination would be to say zero arguments is zero arguments and you get a
zero-length array. We could eliminate the problem with anyelement by saying
the variadic argument can't be the only polymorphic argument.

I disagree. Polymorphism is strong feature and without it, you have to
repeat code. Or maybe divide this problem to two cases: zero typed
variadic arguments, and nnempty polymorphic variadic argument.

Regards
Pavel Stehule

"Pavel Stehule" <pavel.stehule@gmail.com> writes:

2008/12/17 Gregory Stark <stark@enterprisedb.com>:

My inclination would be to say zero arguments is zero arguments and you get a
zero-length array. We could eliminate the problem with anyelement by saying
the variadic argument can't be the only polymorphic argument.

I disagree. Polymorphism is strong feature and without it, you have to
repeat code. Or maybe divide this problem to two cases: zero typed
variadic arguments, and nnempty polymorphic variadic argument.

Yeah, I don't like putting extra restrictions on the polymorphic case
either. Also, see my nearby note about how letting fewer defaults win
over more defaults might be unsafe. Consider

foo (f1 int)
foo (f1 int, f2 variadic int[])

If the system allows f2 to be defaulted to zero elements, then these two
functions would have to be considered ambiguous under the stricter rule.
This would make it *impossible* for the user to override the default
zero-argument behavior, even with the trick of using an additional
function. Under the rules that I'm pushing, the above two declarations
are not ambiguous because you need at least two actual arguments to
match the second one. They would be ambiguous if you explicitly
specified a default for f2, but there's no reason to do so if you want
this type of combination.

regards, tom lane

Tom Lane wrote:

Yeah, I don't like putting extra restrictions on the polymorphic case
either. Also, see my nearby note about how letting fewer defaults win
over more defaults might be unsafe. Consider

foo (f1 int)
foo (f1 int, f2 variadic int[])

If the system allows f2 to be defaulted to zero elements, then these two
functions would have to be considered ambiguous under the stricter rule.
This would make it *impossible* for the user to override the default
zero-argument behavior, even with the trick of using an additional
function.

Hmm, that use case might best be addressed by allowing the variadic
argument to be omitted (or defaulted) if all previous arguments are
omittable.