Re: Implementation of LIMIT on DELETE and UPDATE statements

From: Alvaro Herrera <alvherre(at)atentus(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Yury Bokhoncovich <byg(at)center-f1(dot)ru>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Stephen R(dot) van den Berg" <srb(at)cuci(dot)nl>, <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Implementation of LIMIT on DELETE and UPDATE statements
Date: 2002-09-23 17:33:50
Message-ID: Pine.LNX.4.44.0209231329130.2451-100000@cm-lcon1-46-187.cm.vtr.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Tom Lane dijo:

> Yury Bokhoncovich <byg(at)center-f1(dot)ru> writes:
> > Imagine typical usage of LIMIT/OFFSET: pagination of a web-output.
> > Say, the output is fetched thru "select id,body from articles limit 10
> > offset 20".
> > Now, content-admin, surfing the content and looking to the page say 2,
> > wanna drop all info on THAT page 2.
> > Guess how it could ease the life for programmer?8)

I don't understand. It's somewhat more difficult to grab all the
primary keys of the currently-selected items (and you can put a
Javascript button with "select all in this page"), this I concede. But
how is it better to be unsure if you are really deleting what you want
to delete? Suppose another admin is also deleting and the LIMIT/OFFSET
shifts between the time the page is presented and the button "delete
these" is pressed...

"Hey, PostgreSQL is stupid," they'll say. "How can they offer such an
unsafe misfeature."

--
Alvaro Herrera (<alvherre[a]atentus.com>)
"God is real, unless declared as int"

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Joe Conway 2002-09-23 17:42:58 Re: contrib/dblink regression test failure fix
Previous Message Tom Lane 2002-09-23 17:02:38 Re: contrib/dblink regression test failure fix