Re: [HACKERS] [BUGS] BUG #6572: The example of SPI_execute is bogus
On Thu, Jan 24, 2013 at 04:51:04PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > Would someone make the doc change outlined above? Thanks. > > Sorry, I'd nearly forgotten about this issue. Will see about fixing the > docs. (It looks like some of the comments in execMain.c could use work > too.) Thanks. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [HACKERS] [BUGS] BUG #6572: The example of SPI_execute is bogus
Bruce Momjian writes: > Would someone make the doc change outlined above? Thanks. Sorry, I'd nearly forgotten about this issue. Will see about fixing the docs. (It looks like some of the comments in execMain.c could use work too.) regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [HACKERS] [BUGS] BUG #6572: The example of SPI_execute is bogus
On Wed, Aug 29, 2012 at 01:13:51PM +, Rajeev rastogi wrote: > > From: pgsql-bugs-ow...@postgresql.org [pgsql-bugs-ow...@postgresql.org] on > behalf of Bruce Momjian [br...@momjian.us] > Sent: Wednesday, August 29, 2012 8:46 AM > To: Tom Lane > Cc: Robert Haas; Hitoshi Harada; pgsql-bugs@postgresql.org; > pgsql-hack...@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 writes: > > > On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada > > > wrote: > > >> On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane 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. Would someone please provide answers to these questions, or write a patch? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [HACKERS] [BUGS] BUG #6572: The example of SPI_execute is bogus
From: pgsql-bugs-ow...@postgresql.org [pgsql-bugs-ow...@postgresql.org] on behalf of Bruce Momjian [br...@momjian.us] Sent: Wednesday, August 29, 2012 8:46 AM To: Tom Lane Cc: Robert Haas; Hitoshi Harada; pgsql-bugs@postgresql.org; pgsql-hack...@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 writes: > > On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada wrote: > >> On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
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 writes: > > On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada wrote: > >> On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane 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 http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
