Обсуждение: Concern about new PL/Perl
It seems that in the new PL/Perl, the result of the spi_exec_query
function changes in meaning depending on the command. For a SELECT,
the value of
$res->{rows}
is a reference to an array of the result rows.
For a different command
$res->{rows}
is a scalar containing the number of affected rows. I think this is a
poor design. Couldn't we have a different result field that always
contains the number of rows?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut wrote:
>It seems that in the new PL/Perl, the result of the spi_exec_query
>function changes in meaning depending on the command. For a SELECT,
>the value of
>
>$res->{rows}
>
>is a reference to an array of the result rows.
>
>For a different command
>
>$res->{rows}
>
>is a scalar containing the number of affected rows. I think this is a
>poor design. Couldn't we have a different result field that always
>contains the number of rows?
>
>
I don't recall seeing any reply to this, but I'm inclined to agree with it.
Joshua, any comment from CP?
cheers
andrew
Andrew Dunstan wrote:
> >$res->{rows}
> >
> >is a reference to an array of the result rows.
> >
> >For a different command
> >
> >$res->{rows}
> >
> >is a scalar containing the number of affected rows.
> I don't recall seeing any reply to this, but I'm inclined to agree
> with it.
>
> Joshua, any comment from CP?
I think using "nrows" for the number of rows would be somewhat
consistent with the other PLs.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Andrew, Peter,
> >It seems that in the new PL/Perl, the result of the spi_exec_query
> >function changes in meaning depending on the command. For a SELECT,
> >the value of
> >
> >$res->{rows}
> >
> >is a reference to an array of the result rows.
> >
> >For a different command
> >
> >$res->{rows}
> >
> >is a scalar containing the number of affected rows. I think this is a
> >poor design. Couldn't we have a different result field that always
> >contains the number of rows?
Hmmm ... while contextual data changes is perlish, substituting a scalar for
an arrayref is going a little far. I agree with Peter, if the second # is
needed, {nrows} makes more sense.
--
Josh Berkus
Aglio Database Solutions
San Francisco
Andrew Dunstan wrote:
>
>
> Peter Eisentraut wrote:
>
>> It seems that in the new PL/Perl, the result of the spi_exec_query
>> function changes in meaning depending on the command. For a SELECT,
>> the value of
>>
>> $res->{rows}
>>
>> is a reference to an array of the result rows.
>>
>> For a different command
>>
>> $res->{rows}
>>
>> is a scalar containing the number of affected rows. I think this is
>> a poor design. Couldn't we have a different result field that always
>> contains the number of rows?
>>
>>
>
> I don't recall seeing any reply to this, but I'm inclined to agree
> with it.
>
> Joshua, any comment from CP?
I would agree that seems a little odd ;). Would this be something we
want done for 8.0?
Sincerely,
Joshua D. Drake
>
> cheers
>
> andrew
> _______________________________________________
> Plperlng-devel mailing list
> Plperlng-devel@pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/plperlng-devel
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
Вложения
Josh, > I would agree that seems a little odd ;). Would this be something we > want done for 8.0? I think we'd better. Otherwise, people will get used to the broken syntax. -- Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus <josh@agliodbs.com> writes:
>> I would agree that seems a little odd ;). Would this be something we
>> want done for 8.0?
> I think we'd better. Otherwise, people will get used to the broken syntax.
Agreed. Someone's going to step up and patch this, no?
(Not me --- I've already wasted more hours than I could afford this week
on plperl.)
regards, tom lane
>Agreed. Someone's going to step up and patch this, no? > >(Not me --- I've already wasted more hours than I could afford this week >on plperl.) > > We can do it, but it will have to be after thanksgiving. J > regards, tom lane > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Вложения
On Thu, 18 Nov 2004, Joshua D. Drake wrote: > >> Agreed. Someone's going to step up and patch this, no? >> >> (Not me --- I've already wasted more hours than I could afford this week >> on plperl.) >> > We can do it, but it will have to be after thanksgiving. Humor the Canadian ... when is Thanksgiving? :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Tom Lane said: > Josh Berkus <josh@agliodbs.com> writes: >>> I would agree that seems a little odd ;). Would this be something we >>> want done for 8.0? > >> I think we'd better. Otherwise, people will get used to the broken >> syntax. > > Agreed. Someone's going to step up and patch this, no? > > (Not me --- I've already wasted more hours than I could afford this > week on plperl.) > I knew I should have looked at this closer when Peter made his complaint - it sounded familiar. IIRC it was actually a point I raised about the original code, and it was fixed. At any rate, last night Abhijit Menon-Sen and I looked at the code and got confused becuse it appears to have been fixed ;-). "rows" only contains data and only exists if the result is from a successful select. "processed" is the row count, and is always present. So it's a case of bad documentation, which we will fix very shortly. Sorry for the noise. cheers andrew
> > Humor the Canadian ... when is Thanksgiving? :) Next week.. :) Thursday. > > ---- > Marc G. Fournier Hub.Org Networking Services > (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: > 7615664 -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Вложения
On Fri, 19 Nov 2004, Joshua D. Drake wrote: > >> >> Humor the Canadian ... when is Thanksgiving? :) > > Next week.. :) Thursday. Thank you ... I knew you guys celebrated later then us, just didn't know why ... do you guys celebrate Remembrance Day same as us, or different too? Ours is Nov 11 ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> Thank you ... I knew you guys celebrated later then us, just didn't know > why ... do you guys celebrate Remembrance Day same as us, or different > too? Ours is Nov 11 ... I don't even know what Rememberance Day is ;) Sincerely, Joshua D. Drake > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html -- Command Prompt, Inc., home of PostgreSQL Replication, and plPHP. Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Вложения
"Joshua D. Drake" <jd@commandprompt.com> writes: >> Thank you ... I knew you guys celebrated later then us, just didn't >> know why ... do you guys celebrate Remembrance Day same as us, or >> different too? Ours is Nov 11 ... > > I don't even know what Rememberance Day is ;) WWI ended on November 11, 1918. The British and their (ex-) colonies take the holiday more seriously than we do, possibly because they lost a million dead in that war... We have it too, but we call it Veterans' Day. -Doug
On Fri, 19 Nov 2004 08:24:20 -0800 "Joshua D. Drake" <jd@commandprompt.com> wrote: > > > Thank you ... I knew you guys celebrated later then us, just didn't > > know why ... do you guys celebrate Remembrance Day same as us, or > > different too? Ours is Nov 11 ... > > I don't even know what Rememberance Day is ;) It's what we call Veteran's Day and yes, Marc, it is on the same day as us. -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
On Fri, Nov 19, 2004 at 05:29:20AM -0600, Andrew Dunstan wrote: > Tom Lane said: > > Josh Berkus <josh@agliodbs.com> writes: > >>> I would agree that seems a little odd ;). Would this be something we > >>> want done for 8.0? > > > >> I think we'd better. Otherwise, people will get used to the broken > >> syntax. > > > > Agreed. Someone's going to step up and patch this, no? > > > > (Not me --- I've already wasted more hours than I could afford this > > week on plperl.) > > > > I knew I should have looked at this closer when Peter made his complaint - > it sounded familiar. IIRC it was actually a point I raised about the > original code, and it was fixed. At any rate, last night Abhijit Menon-Sen > and I looked at the code and got confused becuse it appears to have been > fixed ;-). "rows" only contains data and only exists if the result is from a > successful select. "processed" is the row count, and is always present. > > So it's a case of bad documentation, which we will fix very shortly. Sorry > for the noise. Please find attached a patch that fixes this. Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote!
Вложения
David Fetter <david@fetter.org> writes:
>> So it's a case of bad documentation, which we will fix very shortly. Sorry
>> for the noise.
> Please find attached a patch that fixes this.
Applied, thanks.
regards, tom lane