Tom Lane <t...@sss.pgh.pa.us> writes: > Peter Eisentraut <pete...@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.
Can we detect it at run-time? If a recheck happens can we somehow know which columns could be problematic to find updated and check that they're unchanged? I'm pretty sure the answer is no, but I figured I would throw it out there in case it gives anyone an idea. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
