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

2013/1/20 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Sun, Jan 20, 2013 at 2:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> On Sat, Jan 19, 2013 at 3:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> That's utter nonsense. Why wouldn't people expect concat(), for
>>>> example, to work for large (or even just moderate-sized) arrays?
>>
>>> /me blinks.
>>
>>> What does that have to do with anything? IIUC, the question isn't
>>> whether CONCAT() would work for large arrays, but rather for very
>>> large numbers of arrays written out as CONCAT(a1, ..., a10000000).
>>
>> No, the question is what happens with CONCAT(VARIADIC some-array-here),
>> which currently just returns the array as-is, but which really ought
>> to concat all the array elements as if they'd been separate arguments.
>
> Wow, that's pretty surprising behavior.
>
>> 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.

one correction - I would to raise error, if array is larger than
FUNC_MAX_ARGS. But is true, so this limit is for VARIADIC function
synthetic, because parameters are passed in array. On second hand this
is inconsistency.

>
> 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.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company