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