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

Re: variadic function support

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: variadic function support
Date: 2008-06-24 15:10:12
Message-ID: 162867790806240810jc61fd56le8563fe4f7d9a265@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-patches
Hello

this version implements syntax based on argmodes.


CREATE FUNCTION mleast(variadic numeric[]) RETURNS numeric AS $$
    SELECT min($1[i])
       FROM generate_subscripts($1,1) g(i);
$$ LANGUAGE SQL;

Regards
Pavel Stehule

2008/6/24 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> But if I have
>>   foo( a text, b int[])
>> it looks odd if both these calls are legal:
>>   foo('a',1,2,3,)
>>   foo('a',ARRAY[1,2,3])
>> which I understand would be the case with the current patch.
>
> Maybe I misunderstand what is supposed to happen, but I believe that
> if the function is marked VARIADIC then the second case would in fact
> be rejected: the signature of the function for parameter-matching
> purposes is text followed by one or more ints, never text and int[].
>
>> I'm also still curious to know how the following would be handled:
>>   foo(a text[], b text[])
>
> I think a is just text[], full stop.  Only the last parameter is
> interpreted differently for variadic.
>
> 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.
>
>                        regards, tom lane
>

Attachment: variadic.2.0.0.diff
Description: text/x-patch (30.9 KB)

In response to

Responses

pgsql-patches by date

Next:From: Joshua D. DrakeDate: 2008-06-24 15:11:54
Subject: Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
Previous:From: Thomas LeeDate: 2008-06-24 14:16:32
Subject: Re: [UPDATED] A GUC variable to replace PGBE_ACTIVITY_SIZE

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