On Sun, Apr 15, 2012 at 12:29:39PM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada <umi.tanuki@gmail.com> wrote:
> >> On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane <tgl@sss.pgh.pa.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.
Would someone make the doc change outlined above? Thanks.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
