Re: [BUGS] Status of issue 4593
От | Robert Haas |
---|---|
Тема | Re: [BUGS] Status of issue 4593 |
Дата | |
Msg-id | 603c8f070901120947wff5d628t74219be369d3230e@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] Status of issue 4593 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] Status of issue 4593
Re: [BUGS] Status of issue 4593 |
Список | pgsql-hackers |
On Mon, Jan 12, 2009 at 8:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> I can see two ways forward: > >> 1) We document bluntly that ORDER BY + FOR UPDATE can return unordered >> results, or > >> 2) We prohibit ORDER BY + FOR UPDATE, like we do with a number of other >> clauses. (There would be no loss of functionality, because you can run >> the query a second time in the transaction with ORDER BY.) > > That code has been working like this for eight or ten years now and this > is the first complaint, so taking away functionality on the grounds that > someone might happen to update the ordering column doesn't seem like the > answer to me. If the only case where ORDER BY + FOR UPDATE are not strictly compatible is when the columns being updated are the same as the columns of the sort, a blanket prohibition against using the two together seems like it prohibits an awful lot of useful things someone might want to do. Saying that you can run the query a second time as a workaround so there's no loss of functionality is true only if you accept the proposition that performance is not a requirement. ...Robert
В списке pgsql-hackers по дате отправления: