From: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-05 06:39:53 |
Message-ID: | CAP7QgmkvMYAwYw1wXAtxbVOEYVeJs7hBUNFkbgssaCxc_FNa_w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
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:
>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Terrance Chen | 2012-04-05 15:14:42 | Could not find your PostgreSQL installation in /var/lib/pgsql |
Previous Message | Vandoorne, Victor | 2012-04-04 15:31:50 | Re: RES: BUG #6573: The database cluster initialisation failed |
From | Date | Subject | |
---|---|---|---|
Next Message | Yeb Havinga | 2012-04-05 08:05:33 | Re: bugfix for cursor arguments in named notation |
Previous Message | Boszormenyi Zoltan | 2012-04-05 06:02:16 | Re: [PATCH] lock_timeout and common SIGALRM framework |