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"
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 |