2013/1/20 Robert Haas <robertmh...@gmail.com>: > On Sun, Jan 20, 2013 at 2:26 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Robert Haas <robertmh...@gmail.com> writes: >>> On Sat, Jan 19, 2013 at 3:27 PM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
