On Mon, 2009-01-12 at 14:35 -0400, Jeff Davis wrote:
> ate: Mon, 12 Jan 2009 09:52:00 -0800
> On Mon, 2009-01-12 at 08:32 -0500, Tom Lane wrote:
> > 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 they are using FOR UPDATE, they clearly expect concurrent updates.
> If they're using ORDER BY, they clearly expect the results to be in
> order.
>
> So who is the target user of this functionality we're trying to
> protect?
If by the question above you are asking for a rational use-case, I think
I can give you one.
In my Oracle days I used to use select for update order by, in order to
reduce the likelihood of deadlocks. If locks are always taken in the
same order, deadlocks become considerably less likely.
Unfortunately, I took this construct, which as far as I know works fine
in Oracle, and continued to use it in Postgres just assuming that it
would work.
At least now the source of some of my more mysterious deadlocks is
apparent :-)
I'd second the request for at least a warning to be issued.
__
Marc