Tom Lane <[email protected]> writes: > Peter Eisentraut <[email protected]> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
