| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | "Andrew Dunstan" <andrew(at)dunslane(dot)net>, pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: variadic function support |
| Date: | 2008-06-25 02:49:09 |
| Message-ID: | 10489.1214362149@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 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)
> 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.
Well, we should certainly store the parameter type as an array in
proargtypes, because that makes this feature transparent to all the
PLs. However, it doesn't follow that the CREATE FUNCTION syntax
has to specify the array type rather than the element type. I think
the Java precedent might be good reason to go with using the element
type in the function declaration.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | daveg | 2008-06-25 03:57:19 | Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout |
| Previous Message | Tom Lane | 2008-06-25 02:41:07 | Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout |