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: 25939.1333551641@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

umi(dot)tanuki(at)gmail(dot)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?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

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

Browse pgsql-hackers by date

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