From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, Lee McKeeman <lmckeeman(at)opushealthcare(dot)com> |
Subject: | Re: [BUGS] Status of issue 4593 |
Date: | 2009-01-12 13:26:48 |
Message-ID: | 496B4518.4080002@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Peter Eisentraut wrote:
> On Tuesday 06 January 2009 02:03:14 Tom Lane wrote:
>> I don't think there's a bug here, at least not in the sense that it
>> isn't Operating As Designed. But it does seem like we could do with
>> some more/better documentation about exactly how FOR UPDATE works.
>> The sequence of operations is evidently a bit more user-visible than
>> I'd realized.
>
> Well, if the effect of ORDER BY + FOR UPDATE is "it might in fact not be
> ordered", then it's pretty broken IMO. It would be pretty silly by analogy
> for example, if the effect of GROUP BY + FOR UPDATE were "depending on
> concurrent events, it may or may not be fully grouped".
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.)
Comments?
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-12 13:32:38 | Re: [BUGS] Status of issue 4593 |
Previous Message | John R Pierce | 2009-01-12 10:22:58 | Re: Installation problem "...The database cluster initialization failed.." |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-12 13:27:10 | Re: Proposal: new border setting in psql |
Previous Message | Simon Riggs | 2009-01-12 13:22:49 | Re: Recovery Test Framework |