Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order
От | Tom Lane |
---|---|
Тема | Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order |
Дата | |
Msg-id | 6403.1256572455@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Oct 26, 2009 at 10:30 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> One problem with this is that there isn't any good way for someone to >> get back the old behavior if they want to. �Which might be a perfectly >> reasonable thing, eg if they know that no concurrent update is supposed >> to change the sort-key column. �The obvious thing would be to allow >> >> select * from (select * from foo order by col limit 10) ss for update; >> >> to apply the FOR UPDATE last. �Unfortunately, that's not how it works >> now because the FOR UPDATE will get pushed down into the subquery. > Could the desired behavior be obtained using a CTE? Nope, we push FOR UPDATE into WITHs too. I don't really see any way to deal with this without some sort of semantic changes. regards, tom lane
В списке pgsql-hackers по дате отправления: