Re: Variadic parameters vs parameter defaults

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

In response to

Responses

Browse pgsql-hackers by date

  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