Re: [Plperlng-devel] Re: 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(at)pgfoundry(dot)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(at)commandprompt(dot)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(at)agliodbs(dot)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(at)commandprompt(dot)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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Tom Lane said:
> Josh Berkus <josh(at)agliodbs(dot)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(at)hub(dot)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(at)commandprompt(dot)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(at)hub(dot)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(at)hub(dot)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(at)commandprompt(dot)com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL

"Joshua D. Drake" <jd(at)commandprompt(dot)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(at)commandprompt(dot)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(at)druid(dot)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(at)agliodbs(dot)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(at)fetter(dot)org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778

Remember to vote!

David Fetter <david(at)fetter(dot)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