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

Поиск
Список
Период
Сортировка
От Rajeev rastogi
Тема Re: [HACKERS] BUG #6572: The example of SPI_execute is bogus
Дата
Msg-id BF2827DCCE55594C8D7A8F7FFD3AB771313C5825@SZXEML508-MBS.china.huawei.com
обсуждение исходный текст
Ответ на Re: [HACKERS] BUG #6572: The example of SPI_execute is bogus  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: [HACKERS] BUG #6572: The example of SPI_execute is bogus
Список 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 по дате отправления:

Предыдущее
От: stefan@konink.de
Дата:
Сообщение: BUG #7509: x NOT IN (select x from z) extremely slow in compare to select x from y except select x from z;
Следующее
От: Tom Lane
Дата:
Сообщение: Re: hot standby lagging vs warm that is up-to-date