From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Vik Reykja <vikreykja(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: fix corner use case of variadic fuctions usage |
Date: | 2013-01-21 03:23:19 |
Message-ID: | CA+TgmoaOEwPV1nESX5-Y48Qu9Bu492UQxuJtGxWEAio1XSrmaw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Sun, Jan 20, 2013 at 10:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sun, Jan 20, 2013 at 2:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Pavel is claiming it's okay for that to fall over if the array has
>>> more than 100 elements. I disagree, not only for the specific case of
>>> CONCAT(), but with the more general implication that such a limitation
>>> is going to be okay for any VARIADIC ANY function that anyone will ever
>>> write.
>
>> I don't know - how many of those will there really ever be? I mean,
>> people only write functions as VARIADIC as a notational convenience,
>> don't they? If you actually need to pass more than 100 separate
>> pieces of data to a function, sending over 100+ parameters is almost
>> certainly the Wrong Way To Do It.
>
> Well, not necessarily, if they're reasonably expressed as an array.
> I would also point out that there is no corresponding limitation on
> variadic functions that take any type other than ANY. Indeed, despite
> Pavel's claim to the contrary, I'm pretty sure it's seen as a feature
> that there's no specific upper limit to how many parameters you can pass
> to a variadic function when using the "VARIADIC array-value" syntax.
> It's certainly a feature that you can pass a varying number of
> parameters that way, thereby "evading" the syntactic fact that you can't
> pass a varying number of parameters any other way. I don't see how
> come it isn't a feature that you can "evade" the FUNC_MAX_ARGS limit
> that way, or why we'd consider it acceptable for variably-sized
> parameter arrays to have such a small arbitrary limit.
OK, I see. If people are already counting on there being no fixed
limit for variadic functions with a type other than "any", then it
would indeed seem weird to make "any" an exception. I'm not sure how
much practical use case there is for such a thing, but still.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Travers | 2013-01-21 03:55:01 | Re: Re: [HACKERS] Overly strict casting rules? (was: proposal: fix corner use case of variadic fuctions usage) |
Previous Message | Craig Ringer | 2013-01-21 03:15:39 | Re: [HACKERS] Overly strict casting rules? (was: proposal: fix corner use case of variadic fuctions usage) |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-01-21 03:26:59 | Re: [WIP] pg_ping utility |
Previous Message | Tom Lane | 2013-01-21 03:19:02 | Re: Removing PD_ALL_VISIBLE |