Re: final patch - plpgsql: for-in-array
От | Pavel Stehule |
---|---|
Тема | Re: final patch - plpgsql: for-in-array |
Дата | |
Msg-id | AANLkTik4_Vx44dePKTFtGhLtnsBKHzO-0jM_KQEyfzhJ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: final patch - plpgsql: for-in-array (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: final patch - plpgsql: for-in-array
|
Список | 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 >
В списке pgsql-hackers по дате отправления: