Re: [HACKERS] BUG #6572: The example of SPI_execute is bogus - Mailing list pgsql-bugs

From Rajeev rastogi
Subject Re: [HACKERS] BUG #6572: The example of SPI_execute is bogus
Date
Msg-id BF2827DCCE55594C8D7A8F7FFD3AB771313C5825@SZXEML508-MBS.china.huawei.com
Whole thread Raw
In response to Re: [HACKERS] BUG #6572: The example of SPI_execute is bogus  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [HACKERS] BUG #6572: The example of SPI_execute is bogus
List pgsql-bugs
________________________________________
From: pgsql-bugs-owner@postgresql.org [pgsql-bugs-owner@postgresql.org] on behalf of Bruce Momjian [bruce@momjian.us]
Sent: Wednesday, August 29, 2012 8:46 AM
To: Tom Lane
Cc: Robert Haas; Hitoshi Harada; pgsql-bugs@postgresql.org; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [BUGS] BUG #6572: The example of SPI_execute is bogus

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.


I would like to work on this documentation bug.
As per analysis I am planning to update following SPI function:
1. SPI_Execute: Here we will mention that argument count is used only for the kind of command which returns result i.e.
allkind of SELECT and DML with returning clause. count is ignored for any other kind of commands. I will add one
examplealso to indicate the difference. 
2. SPI_execute_plan_with_paramlist: Here we can give just reference to SPI_execute i.e. I will mention that count has
sameinterpretation as in SPI_execute. 
3. SPI_execp: Here we can give just reference to SPI_execute i.e. I will mention that count has same interpretation as
inSPI_execute. 

Please provide your feedback.

Thanks and Regards,
Kumar Rajeev Rastogi
Cell No - +91 8971367787


pgsql-bugs by date:

Previous
From: stefan@konink.de
Date:
Subject: BUG #7509: x NOT IN (select x from z) extremely slow in compare to select x from y except select x from z;
Next
From: Tom Lane
Date:
Subject: Re: hot standby lagging vs warm that is up-to-date