Re: final patch - plpgsql: for-in-array
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Merlin Moncure <mmoncure@gmail.com>,
Jaime Casanova <jaime@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2010-11-18T16:37:06Z
Lists: pgsql-hackers
2010/11/18 Tom Lane <tgl@sss.pgh.pa.us>: > Merlin Moncure <mmoncure@gmail.com> writes: >> On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Yes, which begs the question of why bother at all. > >> Pavel's performance argument is imnsho valid. > > Well, that argument is unsupported by any evidence, so far as I've seen. > > More to the point, if there is indeed an interesting performance win > here, we could get the same win by internally optimizing the existing > syntax. That would provide the benefit to existing code not just > new code; and it would avoid foreclosing our future options for > extending FOR in not-so-redundant ways. sorry, but I don't agree. I don't think, so there are some big space for optimizing - and if then it means much more code complexity for current expr executor. Next - FOR IN ARRAY takes fields from array on request - and it is possible, because a unpacking of array is controlled by statement - it's impossible do same when unpacking is inside other functions with same effectivity. Regards Pavel Stehule > > regards, tom lane >