Tom Lane wrote:
> > 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...
I see no reason to add stuff to UPDATE/DELETE when a subquery does the
job just as well. It just seems like bloat.
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
In response to
pgsql-patches by date
|Next:||From: Bruce Momjian||Date: 2002-09-23 05:26:25|
|Subject: HISTORY updated for 7.3beta2|
|Previous:||From: Tom Lane||Date: 2002-09-23 03:10:53|
|Subject: Re: Implementation of LIMIT on DELETE and UPDATE statements (rel to 7.2.1) |