| 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: | Whole Thread | Raw Message | 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 |