Re: Implementation of LIMIT on DELETE and UPDATE statements

Hello!

On Mon, 23 Sep 2002, Tom Lane wrote:

> 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

Agreed. But if records are inserted by INSERT (times) values (now()) and
those are selected ORDER BY times - the result is probably well
determined.;)

> planner is entitled to (and often does) choose different query plans
> depending on the limit/offset values.

Hm...I had always supposed that LIMIT/OFFSET is a trick to get the
functionality of cursors w/o their overhead.
And nobody wonders when there's sequential scan in cursor upto a required
bunch of records, then bulk delete/update of those.

I don't insist on the feature, just some thoughts.

BTW, doing limit/offset w/o ORDER BY is useless anyway IMHO.:)

--
WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group.
Phone: +7 (3832) 106228, ext.140, E-mail: byg(at)center-f1(dot)ru(dot)
Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.