Thread: 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? > > http://www.postgresql.org/docs/faq -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote!
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
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!
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? > > http://www.postgresql.org/docs/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-----