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 по дате отправления: