Re: final patch - plpgsql: for-in-array

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

In response to

Responses

Browse pgsql-hackers by date

  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)