Re: Implementation of LIMIT on DELETE and UPDATE statements
| От | Tom Lane |
|---|---|
| Тема | Re: Implementation of LIMIT on DELETE and UPDATE statements |
| Дата | |
| Msg-id | 20865.1032788062@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Implementation of LIMIT on DELETE and UPDATE statements (Yury Bokhoncovich <byg@center-f1.ru>) |
| Ответы |
Re: Implementation of LIMIT on DELETE and UPDATE statements
Re: Implementation of LIMIT on DELETE and UPDATE statements |
| Список | pgsql-patches |
Yury Bokhoncovich <byg@center-f1.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
В списке pgsql-patches по дате отправления: