Skip site navigation (1) Skip section navigation (2)

Re: variadic function support

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: variadic function support
Date: 2008-06-24 05:39:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
2008/6/24 Andrew Dunstan <andrew(at)dunslane(dot)net>:
> Tom Lane wrote:
>> Your point about the syntax is good though.  It would be better if
>> the syntax were like
>>        create function foo (a text, variadic b int[])
>> or maybe even better
>>        create function foo (a text, variadic b int)
>> since (a) this makes it much more obvious to the reader what the
>> function might match, and (b) it leaves the door open for marking
>> multiple parameters as variadic, if we can figure out what that means.
> Yes. I understand from the family Java expert that (surface syntax issues
> aside) the second is similar to the way Java does this, in fact, so there's
> some precedent. That would mean that your first would actually mean each
> variadic arg has to be an array of ints, which we might well want to provide
> for.
> So with that modification I'll be lots happier with the feature.

I don't see problem with your syntax. It well block combination OUT
and VARIADIC parameter - my one request, variadic parameter have to be
array. It's more consistent with following procedure implementation -
inside procedures is really array.

CREATE OR REPLACE least(varidic values numeric[]) --< ARRAY
RETURNS numeric AS $$
SELECT $1[i] --< ARRAY

Pavel Stehule

p.s. with one exception "any", because there isn't possible array from "any"

> cheers
> andrew

In response to


pgsql-patches by date

Next:From: Pavel StehuleDate: 2008-06-24 06:01:34
Subject: Re: variadic function support
Previous:From: Pavel StehuleDate: 2008-06-24 05:30:52
Subject: Re: variadic function support

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group