Re: [HACKERS] BUG #6572: The example of SPI_execute is bogus

From: Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] BUG #6572: The example of SPI_execute is bogus
Date: 2012-08-29 13:13:51
Message-ID: BF2827DCCE55594C8D7A8F7FFD3AB771313C5825@SZXEML508-MBS.china.huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

________________________________________
From: pgsql-bugs-owner(at)postgresql(dot)org [pgsql-bugs-owner(at)postgresql(dot)org] on behalf of Bruce Momjian [bruce(at)momjian(dot)us]
Sent: Wednesday, August 29, 2012 8:46 AM
To: Tom Lane
Cc: Robert Haas; Hitoshi Harada; pgsql-bugs(at)postgresql(dot)org; pgsql-hackers(at)postgresql(dot)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(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.

> 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. all kind of SELECT and DML with returning clause. count is ignored for any other kind of commands. I will add one example also 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 same interpretation 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 in SPI_execute.

Please provide your feedback.

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Merlin Moncure 2012-08-29 13:55:46 Re: BUG #6489: Alter table with composite type/table
Previous Message stefan 2012-08-29 10:31:27 BUG #7509: x NOT IN (select x from z) extremely slow in compare to select x from y except select x from z;

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-08-29 14:19:48 Re: TRUE/FALSE vs true/false
Previous Message Bruce Momjian 2012-08-29 12:51:40 Re: FATAL: bogus data in lock file "postmaster.pid": ""