Re: [BUGS] Status of issue 4593

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?

In response to

Responses

Browse pgsql-bugs by date

  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.."

Browse pgsql-hackers by date

  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