On Sun, Apr 15, 2012 at 12:29:39PM -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada <umi.tan...@gmail.com> wrote: > >> On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane <t...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
