Re: Variadic parameters vs parameter defaults

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Brendan Jurd" <direvus(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Variadic parameters vs parameter defaults
Date: 2008-12-17 04:03:06
Message-ID: 20958.1229486586@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Brendan Jurd" <direvus(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2008-12-17 05:27:09 Re: Another issue in default-values patch: defaults expanded too soon
Previous Message Robert Haas 2008-12-17 04:00:31 Re: Another issue in default-values patch: defaults expanded too soon