From: | "Brendan Jurd" <direvus(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Variadic parameters vs parameter defaults |
Date: | 2008-12-17 03:43:53 |
Message-ID: | 37ed240d0812161943k77a2130cna3688f8bb7ff133b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 17, 2008 at 12:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2008-12-17 04:00:31 | Re: Another issue in default-values patch: defaults expanded too soon |
Previous Message | Tom Lane | 2008-12-17 03:31:15 | Re: [ADMIN] shared_buffers and shmmax |