From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: final patch - plpgsql: for-in-array |
Date: | 2010-11-18 22:29:36 |
Message-ID: | 12307.1290119376@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2010/11/18 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
>> I fail to see how this supports the FOR-IN-array development though. It
>> will just be another unused construct for most people, no?
> maybe I don't understand well, but patch FOR-IN-ARRAY has a documentation
UNNEST is documented too. Adding still more features doesn't really
improve matters for people who haven't memorized the documentation;
it only makes it even harder for them to find out what they should be
using. (More features != better)
To my mind, the complaint about subscripting being slow suggests that we
ought to fix subscripting, not introduce a nonstandard feature that will
make certain use-cases faster if people rewrite their code to use it.
I think it would probably not be terribly hard to arrange forcible
detoasting of an array variable's value the first time it gets
subscripted, for instance. Of course that only fixes some use-cases;
but it would help, and it helps without requiring people to change their
code.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2010-11-18 23:06:07 | Re: final patch - plpgsql: for-in-array |
Previous Message | Tom Lane | 2010-11-18 22:17:10 | Re: Latches with weak memory ordering (Re: max_wal_senders must die) |