Re: [BUGS] Status of issue 4593 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [BUGS] Status of issue 4593
Date
Msg-id 603c8f070901120947wff5d628t74219be369d3230e@mail.gmail.com
Whole thread Raw
In response to Re: [BUGS] Status of issue 4593  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUGS] Status of issue 4593  (Jeff Davis <pgsql@j-davis.com>)
Re: [BUGS] Status of issue 4593  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Jan 12, 2009 at 8:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter_e@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.

If the only case where ORDER BY + FOR UPDATE are not strictly
compatible is when the columns being updated are the same as the
columns of the sort, a blanket prohibition against using the two
together seems like it prohibits an awful lot of useful things someone
might want to do.  Saying that you can run the query a second time as
a workaround so there's no loss of functionality is true only if you
accept the proposition that performance is not a requirement.

...Robert


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Recovery Test Framework
Next
From: Jeff Davis
Date:
Subject: Re: [BUGS] Status of issue 4593