On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada <umi.tan...@gmail.com> wrote: > On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> umi.tan...@gmail.com writes: >>> http://www.postgresql.org/docs/9.1/static/spi-spi-execute.html >> >>> === >>> SPI_execute("INSERT INTO foo SELECT * FROM bar", false, 5); >>> will allow at most 5 rows to be inserted into the table. >>> === >> >>> This seems not true unless I'm missing something. >> >> Hmm ... that did work as described, until we broke it :-(. This is an >> oversight in the 9.0 changes that added separate ModifyTuple nodes to >> plan trees. ModifyTuple doesn't return after each updated row, unless >> there's a RETURNING clause; which means that the current_tuple_count >> check logic in ExecutePlan() no longer stops execution as intended. >> >> Given the lack of complaints since 9.0, maybe we should not fix this >> but just redefine the new behavior as being correct? But it seems >> mighty inconsistent that the tuple limit would apply if you have >> RETURNING but not when you don't. In any case, the ramifications >> are wider than one example in the SPI docs. >> >> Thoughts? > > To be honest, I was surprised when I found tcount parameter is said to > be applied to even INSERT. I believe people think that parameter is > to limit memory consumption when returning tuples thus it'd be applied > for only SELECT or DML with RETURNING. So I'm +1 for non-fix but > redefine the behavior. Who wants to limit the number of rows > processed inside the backend, from SPI?
Yeah. I think it would be a good idea for UPDATE and DELETE to expose a LIMIT option, but I can't really see the virtue in making that functionality available only through SPI. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
