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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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:
>>> 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.

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

Okay, apparently nobody cares about RETURNING behaving differently from
non-RETURNING, so the consensus is to redefine the current behavior as
correct. That means what we need is to go through the docs and see what
places need to be updated (and, I guess, back-patch the changes to 9.0).
I will get to this if nobody else does, but not right away.

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

FWIW, I'm not excited about that. You can get well-defined behavior
today from a SELECT/LIMIT drawing from a writable CTE (namely, that
the UPDATE/DELETE runs to completion but you only see a subset of
its RETURNING result). LIMIT directly on the UPDATE/DELETE would be
ill-defined, unless perhaps you want to also invent a way of specifying
the order in which rows get selected for update; but I don't want to
go there.

regards, tom lane