Skip site navigation (1) Skip section navigation (2)

Re: BUG #6572: The example of SPI_execute is bogus

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: BUG #6572: The example of SPI_execute is bogus
Date: 2012-04-13 22:53:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers
On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> wrote:
> On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> umi(dot)tanuki(at)gmail(dot)com writes:
>>> ===
>>> 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
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2012-04-14 01:11:48
Subject: Re: Command counter increment vs updating an active snapshot
Previous:From: Tom LaneDate: 2012-04-13 22:22:35
Subject: Re: Patch: add timing of buffer I/O requests

pgsql-bugs by date

Next:From: Greg StarkDate: 2012-04-14 01:34:16
Subject: Re: BUG #6587: Limit on a query is mis-documented
Previous:From: mboldiDate: 2012-04-13 19:40:35
Subject: BUG #6587: Limit on a query is mis-documented

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group