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 PostgreSQLJosh,
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 PostgreSQLOn 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?
--
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!
Attachments:
plperl.difftext/plain; charset=us-asciiDownload
Index: doc/src/sgml/plperl.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/plperl.sgml,v
retrieving revision 2.30
diff -c -r2.30 plperl.sgml
*** doc/src/sgml/plperl.sgml 6 Nov 2004 14:32:10 -0000 2.30
--- doc/src/sgml/plperl.sgml 19 Nov 2004 18:52:34 -0000
***************
*** 174,189 ****
<programlisting>
$rv = spi_exec_query('SELECT * FROM my_table', 5);
</programlisting>
! This returns up to 5 rows from the table
! <literal>my_table</literal>. If <literal>my_table</literal>
! has a column <literal>my_column</literal>, it could be accessed
! like this:
<programlisting>
$foo = $rv->{rows}[$i]->{my_column};
</programlisting>
! The total number of rows returned can be accessed like this:
<programlisting>
! $nrows = @{$rv->{rows}};
</programlisting>
</para>
--- 174,190 ----
<programlisting>
$rv = spi_exec_query('SELECT * FROM my_table', 5);
</programlisting>
! This returns up to 5 rows from the table
! <literal>my_table</literal>. If <literal>my_table</literal>
! has a column <literal>my_column</literal>, you can get the value that
! value from row <literal>$i</literal> from a
! <command>SELECT</command> like this:
<programlisting>
$foo = $rv->{rows}[$i]->{my_column};
</programlisting>
! The total number of rows returned from a <command>SELECT</command> query can be accessed like this:
<programlisting>
! $nrows = $rv->{processed}
</programlisting>
</para>
***************
*** 200,206 ****
</programlisting>
To get the number of rows affected, do:
<programlisting>
! $nrows = $rv->{rows};
</programlisting>
</para>
</listitem>
--- 201,207 ----
</programlisting>
To get the number of rows affected, do:
<programlisting>
! $nrows = $rv->{processed};
</programlisting>
</para>
</listitem>