Re: proposal: fix corner use case of variadic fuctions usage

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 05:04:55
Message-ID: CAFj8pRDJWXGckw_DBMiTLjB-FDOXCa_xG84+EhAUC1TkV0KwOA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

2013/1/21 Robert Haas <robertmhaas(at)gmail(dot)com>:
> 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.

after sleeping and some thinking about topic - yes - Tom opinion is
correct too - theoretically we can count all variadic argument as one.

Exception is just VARIADIC "any" when is called usually - it can be
only better documented - I don't see a problem now

Regards

Pavel

>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company

In response to

Browse pgsql-general by date

  From Date Subject
Next Message bhanu udaya 2013-01-21 06:17:35 Re: pg_Restore
Previous Message Adrian Klaver 2013-01-21 04:42:58 Re: Understanding TIMESTAMP WITH TIME ZONE

Browse pgsql-hackers by date

  From Date Subject
Next Message Vivek Singh Raghuwanshi 2013-01-21 05:23:49 Error Building rpm
Previous Message Tom Lane 2013-01-21 04:11:44 Re: [PATCH] Fix off-by-one in PQprintTuples()