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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
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-20 19:26:30
Message-ID: 26966.1358709990@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andrew Dunstan 2013-01-20 19:35:39 Re: proposal: fix corner use case of variadic fuctions usage
Previous Message Alejandro Carrillo 2013-01-20 19:22:40 Re: not(t_xmax = 0)

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-01-20 19:32:29 Re: Further pg_upgrade analysis for many tables
Previous Message Tom Lane 2013-01-20 19:11:48 Re: Further pg_upgrade analysis for many tables