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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: umi(dot)tanuki(at)gmail(dot)com
Cc: 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-04 15:00:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers
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.


			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2012-04-04 15:10:32
Subject: Re: bugfix for cursor arguments in named notation
Previous:From: Tom LaneDate: 2012-04-04 14:46:28
Subject: Re: Speed dblink using alternate libpq tuple storage

pgsql-bugs by date

Next:From: Vandoorne, VictorDate: 2012-04-04 15:31:50
Subject: Re: RES: BUG #6573: The database cluster initialisation failed
Previous:From: Ashesh VashiDate: 2012-04-04 12:45:02
Subject: Re: RES: BUG #6573: The database cluster initialisation failed

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