suggested warning about perl nested named subroutines
I propose to add the following to the plperl docs, following recent
problems.
comments?
cheers
andrew
Index: plperl.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v
retrieving revision 2.45
diff -c -r2.45 plperl.sgml
*** plperl.sgml 24 Aug 2005 19:16:49 -0000 2.45
--- plperl.sgml 12 Oct 2005 00:36:33 -0000
***************
*** 53,64 ****
# PL/Perl function body
$$ LANGUAGE plperl;
</programlisting>
! The body of the function is ordinary Perl code. A PL/Perl function must
always return a scalar value. You can return more complex structures
(arrays, records, and sets) by returning a reference, as discussed
below.
Never return a list.
</para> <para>
The syntax of the <command>CREATE FUNCTION</command> command requires
the function body to be written as a string constant. It is usually
--- 53,76 ----
# PL/Perl function body
$$ LANGUAGE plperl;
</programlisting>
! The body of the function is ordinary Perl code. In fact, the PL/Perl
! glue code wraps it inside a Perl subroutine. A PL/Perl function must
always return a scalar value. You can return more complex structures
(arrays, records, and sets) by returning a reference, as discussed
below.
Never return a list.
</para>+ <note>
+ <para>
+ The use of named nested subroutines is dangerous in Perl,
especially if
+ they refer to lexical variables in the enclosing scope. Because
a PL/Perl
+ function is wrapped in a subroutine, any named subroutine you
create will
+ be nested. In general, it is far safer to create anonymous
subroutines
+ which you call via a coderef. See the <literal>perldiag</literal>
+ man page for more details.
+ </para>
+ </note>
+
<para>
The syntax of the <command>CREATE FUNCTION</command> command requires
the function body to be written as a string constant. It is usually
On Tue, Oct 11, 2005 at 08:40:21PM -0400, Andrew Dunstan wrote:
I propose to add the following to the plperl docs, following recent
problems.comments?
Examples of each and how they'd break would be good.
Cheers,
D
cheers
andrew
Index: plperl.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v retrieving revision 2.45 diff -c -r2.45 plperl.sgml *** plperl.sgml 24 Aug 2005 19:16:49 -0000 2.45 --- plperl.sgml 12 Oct 2005 00:36:33 -0000 *************** *** 53,64 **** # PL/Perl function body $$ LANGUAGE plperl; </programlisting> ! The body of the function is ordinary Perl code. A PL/Perl function must always return a scalar value. You can return more complex structures (arrays, records, and sets) by returning a reference, as discussed below. Never return a list. </para><para> The syntax of the <command>CREATE FUNCTION</command> command requires the function body to be written as a string constant. It is usually --- 53,76 ---- # PL/Perl function body $$ LANGUAGE plperl; </programlisting> ! The body of the function is ordinary Perl code. In fact, the PL/Perl ! glue code wraps it inside a Perl subroutine. A PL/Perl function must always return a scalar value. You can return more complex structures (arrays, records, and sets) by returning a reference, as discussed below. Never return a list. </para>+ <note> + <para> + The use of named nested subroutines is dangerous in Perl, especially if + they refer to lexical variables in the enclosing scope. Because a PL/Perl + function is wrapped in a subroutine, any named subroutine you create will + be nested. In general, it is far safer to create anonymous subroutines + which you call via a coderef. See the <literal>perldiag</literal> + man page for more details. + </para> + </note> + <para> The syntax of the <command>CREATE FUNCTION</command> command requires the function body to be written as a string constant. It is usually---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
On Tue, Oct 11, 2005 at 09:58:22PM -0400, Neil Conway wrote:
On Tue, 2005-11-10 at 18:36 -0700, David Fetter wrote:
Examples of each and how they'd break would be good.
Is that needed? Seems like overkill to me.
IMHO, yes, and no, respectively. If there's an example, there's fewer
frustrated people pestering lists about it.
Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
Import Notes
Reply to msg id not found: 1129082302.27676.61.camel@localhost.localdomain
On Tue, 2005-11-10 at 18:36 -0700, David Fetter wrote:
Examples of each and how they'd break would be good.
Is that needed? Seems like overkill to me.
-Neil
David Fetter wrote:
On Tue, Oct 11, 2005 at 09:58:22PM -0400, Neil Conway wrote:
On Tue, 2005-11-10 at 18:36 -0700, David Fetter wrote:
Examples of each and how they'd break would be good.
Is that needed? Seems like overkill to me.
IMHO, yes, and no, respectively. If there's an example, there's fewer
frustrated people pestering lists about it.
If this were a Postgres problem I'd agree with you. But it isn't, really
- it's a Perl problem, which is properly documented in the Perl docs, to
which this note refers.
I don't think we'll get flooded with problems - Greg is the first person
who has complained about it in the 9 months or so since version 8.0 was
released.
cheers
andrew
On Tue, 2005-11-10 at 18:55 -0700, David Fetter wrote:
IMHO, yes, and no, respectively. If there's an example, there's fewer
frustrated people pestering lists about it.
There is something to be said for brevity: spending a lot of prose on an
example of an obscure problem means the documentation is more difficult
to understand and less useful to most users.
Of course, that's not to say this particular problem is sufficiently
obscure that an example isn't worthwhile (I don't really know) -- but
the attitude that examples are always good is misguided IMHO.
-Neil
On Tue, Oct 11, 2005 at 10:01:02PM -0400, Andrew Dunstan wrote:
David Fetter wrote:
On Tue, Oct 11, 2005 at 09:58:22PM -0400, Neil Conway wrote:
On Tue, 2005-11-10 at 18:36 -0700, David Fetter wrote:
Examples of each and how they'd break would be good.
Is that needed? Seems like overkill to me.
IMHO, yes, and no, respectively. If there's an example, there's
fewer frustrated people pestering lists about it.If this were a Postgres problem I'd agree with you. But it isn't,
really - it's a Perl problem, which is properly documented in the
Perl docs, to which this note refers.I don't think we'll get flooded with problems - Greg is the first
person who has complained about it in the 9 months or so since
version 8.0 was released.
Fair enough :)
Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
Patch applied. Thanks.
---------------------------------------------------------------------------
Andrew Dunstan wrote:
I propose to add the following to the plperl docs, following recent
problems.comments?
cheers
andrew
Index: plperl.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v retrieving revision 2.45 diff -c -r2.45 plperl.sgml *** plperl.sgml 24 Aug 2005 19:16:49 -0000 2.45 --- plperl.sgml 12 Oct 2005 00:36:33 -0000 *************** *** 53,64 **** # PL/Perl function body $$ LANGUAGE plperl; </programlisting> ! The body of the function is ordinary Perl code. A PL/Perl function must always return a scalar value. You can return more complex structures (arrays, records, and sets) by returning a reference, as discussed below. Never return a list. </para><para> The syntax of the <command>CREATE FUNCTION</command> command requires the function body to be written as a string constant. It is usually --- 53,76 ---- # PL/Perl function body $$ LANGUAGE plperl; </programlisting> ! The body of the function is ordinary Perl code. In fact, the PL/Perl ! glue code wraps it inside a Perl subroutine. A PL/Perl function must always return a scalar value. You can return more complex structures (arrays, records, and sets) by returning a reference, as discussed below. Never return a list. </para>+ <note> + <para> + The use of named nested subroutines is dangerous in Perl, especially if + they refer to lexical variables in the enclosing scope. Because a PL/Perl + function is wrapped in a subroutine, any named subroutine you create will + be nested. In general, it is far safer to create anonymous subroutines + which you call via a coderef. See the <literal>perldiag</literal> + man page for more details. + </para> + </note> + <para> The syntax of the <command>CREATE FUNCTION</command> command requires the function body to be written as a string constant. It is usually---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
If this were a Postgres problem I'd agree with you. But it isn't, really
- it's a Perl problem, which is properly documented in the Perl docs, to
which this note refers.
Well, it's really a problem with our implementation of pl/perl. I don't think
it's entirely fair to simply say it's a perl problem and point people at a
perldoc page. An example would definitely be nice - it is not as if the pl/perl
docs are growing out of control or anything. :)
I don't think we'll get flooded with problems - Greg is the first person
who has complained about it in the 9 months or so since version 8.0 was
released.
Call me cutting edge. :) I ran into this when creating an article about
how wonderful pl/perl is. I just don't think many people are using it yet.
Hopefully that will change after my article comes out and I convince all
those perl hackers out there that procedural languages don't need to be
painful anymore.
+1 on the 5.6 dependency: it came out in early 2000. By way of comparison,
PostgreSQL was at version 6.5.3 when perl 5.6 came out.
One more annoyance, while I'm here: what's with "spi_exec_query()"? Is that
the best name we could come up with? How about something short and simple,
in the same vein as "elog()", such as "sql()" ? :)
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200510121205
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iD8DBQFDTT+1vJuQZxSWSsgRApbmAKCTQWMS3RQIY4R0Bby0Xj8hMZ9mqgCfdskt
q5J6e0AaIOFaVI+pXnGGWCo=
Greg Sabino Mullane wrote:
If this were a Postgres problem I'd agree with you. But it isn't, really
- it's a Perl problem, which is properly documented in the Perl docs, to
which this note refers.Well, it's really a problem with our implementation of pl/perl. I don't think
it's entirely fair to simply say it's a perl problem and point people at a
perldoc page. An example would definitely be nice - it is not as if the pl/perl
docs are growing out of control or anything. :)
Submit a patch then.
+1 on the 5.6 dependency: it came out in early 2000. By way of comparison,
PostgreSQL was at version 6.5.3 when perl 5.6 came out.
Sure. But there is an older, slightly more klunky, mechanism should work
just as well in this case (see my script).
One more annoyance, while I'm here: what's with "spi_exec_query()"? Is that
the best name we could come up with? How about something short and simple,
in the same vein as "elog()", such as "sql()" ? :)
I don't much like it either. But it's there from 8.0, so we really
shouldn't change it now. OTOH I don't like also having spi_query, but
nobody has kicked up much. If we're going to change that we need to
change it real fast.
cheers
andrew
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
One more annoyance, while I'm here: what's with "spi_exec_query()"? Is that
the best name we could come up with? How about something short and simple,
in the same vein as "elog()", such as "sql()" ? :)
I don't much like it either. But it's there from 8.0, so we really
shouldn't change it now. OTOH I don't like also having spi_query, but
nobody has kicked up much. If we're going to change that we need to
change it real fast.
We don't need to change it and break backwards-compatibilty, but we could
easily add in a synonym and deprecate spi_*. I prefer sql() or exec(),
although the latter is a little to close to "EXECUTE". Maybe do() in
the spirit of DBI (although it returns result sets, so that could be
potentially confusing). Other ideas? I'm assuming this is a 8.2 thing,
so we have plenty of time. :)
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200510231734
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iD8DBQFDXAJBvJuQZxSWSsgRAs5qAJ9xcw/lcEcOsD3gBcc6o6xQcC4HTgCeNhKQ
aofyqUREbX0jYJD+CVY3FQI=
=1XDK
-----END PGP SIGNATURE-----