| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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 18:40:15 |
| Message-ID: | CA+TgmobSq5m5Cbkb3gmrbYSPLvtQ9NmZkqGh_mS46h_Znd36bQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
On Sat, Jan 19, 2013 at 3:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> disagree - non variadic manner call should not be used for walk around
>> FUNC_MAX_ARGS limit. So there should not be passed big array.
>
> 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).
I don't understand why an appropriately-placed check against
FUNC_MAX_ARGS does anything other than enforce a limit we already
have. Or are we currently not consistently enforcing that limit?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alejandro Carrillo | 2013-01-20 19:22:40 | Re: not(t_xmax = 0) |
| Previous Message | Robert Haas | 2013-01-20 18:37:21 | Re: proposal: fix corner use case of variadic fuctions usage |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2013-01-20 18:42:29 | Re: Further pg_upgrade analysis for many tables |
| Previous Message | Robert Haas | 2013-01-20 18:37:21 | Re: proposal: fix corner use case of variadic fuctions usage |