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
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 |
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 |