From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Jeff Davis" <pgsql(at)j-davis(dot)com>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: variadic function support |
Date: | 2008-07-14 07:26:41 |
Message-ID: | 162867790807140026v67eaa804kdb15ac848820d49d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
>
> As far as the "variadic int" versus "variadic int[]" business, I'm
> starting to agree with Pavel that "variadic int[]" offers less potential
> for confusion. In particular, it seems to make it more obvious for the
> function author that the argument he receives is an array. Also, the
> other one would mean that what we put into pg_proc.proargtypes doesn't
> agree directly with what the user thinks the argument types are. While
> I think we could force that to work, it's not exactly satisfying the
> principle of least surprise.
>
>
> One issue that just occurred to me: what if a variadic function wants to
> turn around and call another variadic function, passing the same array
> argument on to the second one? This is closely akin to the problem
> faced by C "..." functions, and the solutions are pretty ugly (sprintf
> vs vsprintf for instance). Can we do any better? At least in the
> polymorphic case, I'm not sure we can :-(.
>
> regards, tom lane
>
maybe with some flag like PARAMS?
SELECT least(PARAMS ARRAY[1,2,3,4,5,6])
Regards
Pavel Stehule
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2008-07-14 13:17:32 | Re: variadic function support |
Previous Message | Pavan Deolasee | 2008-07-14 03:50:02 | Re: [PATCHES] VACUUM Improvements - WIP Patch |