| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Yury Bokhoncovich <byg(at)center-f1(dot)ru> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)atentus(dot)com>, "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 13:34:22 |
| Message-ID: | 20865.1032788062@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
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)
Only until the first time he drops the wrong page that way.
The above is really a perfect example of why this feature isn't safe:
it would lead people to make unwarranted assumptions. The fact that
such-and-such a tuple appeared second in the output of LIMIT 10 OFFSET
20 does *not* mean that it would be selected by LIMIT 1 OFFSET 21. The
planner is entitled to (and often does) choose different query plans
depending on the limit/offset values.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-09-23 13:41:40 | Re: DROP COLUMN misbehaviour with multiple inheritance |
| Previous Message | Hannu Krosing | 2002-09-23 09:54:41 | Re: DROP COLUMN misbehaviour with multiple inheritance |