Re: Implementation of LIMIT on DELETE and UPDATE statements (rel to 7.2.1)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)atentus(dot)com>
Cc: srb(at)cuci(dot)nl (Stephen R(dot) van den Berg), pgsql-patches(at)postgresql(dot)org
Subject: Re: Implementation of LIMIT on DELETE and UPDATE statements (rel to 7.2.1)
Date: 2002-09-23 03:10:53
Message-ID: 14335.1032750653@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

> srb(at)cuci(dot)nl (Stephen R. van den Berg) escribi:
>> Incidentally, using a SELECT without an ORDER BY but with a LIMIT is
>> documented to give unpredictable results, yet users are expected cope with
>> this fact, but are expected to have problems with a similar fact in
>> an UPDATE or DELETE statement?

Well, IMHO there's a big difference in documented unpredictable output
from a documented-unpredictable query, as opposed to
documented-unpredictable changes in the database state. There is not
a lot of use for the latter AFAICS.

Alvaro Herrera <alvherre(at)atentus(dot)com> writes:
> as I already said, the feature has some value with the ORDER BY added,
> and the LIMIT/OFFSET thing expanded to allow expressions (this last part
> is in TODO).

I'd have more confidence in the usefulness of the idea if it included
ORDER BY to make the LIMIT predictable. But before you run off and
implement that: does MySQL support such a thing? If not, the argument
of improving compatibility still doesn't hold any water...

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2002-09-23 03:12:43 Re: Implementation of LIMIT on DELETE and UPDATE statements
Previous Message Bruce Momjian 2002-09-23 01:53:25 Re: Memory Errors...