On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> umi.tanuki@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?
Thanks,
--
Hitoshi Harada
