Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit aed0829

Browse files
committed
Improve warning about creating nested named subroutines in plperl.
Per discussion.
1 parent a2239b9 commit aed0829

File tree

1 file changed

+8
-7
lines changed

1 file changed

+8
-7
lines changed

doc/src/sgml/plperl.sgml

Lines changed: 8 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.80 2010/02/12 19:35:25 adunstan Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.81 2010/02/25 03:08:07 tgl Exp $ -->
22

33
<chapter id="plperl">
44
<title>PL/Perl - Perl Procedural Language</title>
@@ -85,12 +85,13 @@ $$ LANGUAGE plperl;
8585
<para>
8686
The use of named nested subroutines is dangerous in Perl, especially if
8787
they refer to lexical variables in the enclosing scope. Because a PL/Perl
88-
function is wrapped in a subroutine, any named subroutine you create will
89-
be nested. In general, it is far safer to create anonymous subroutines
90-
which you call via a coderef. See <literal>Variable "%s" will not stay shared</literal>
91-
and <literal>Variable "%s" is not available</literal> in the
92-
<citerefentry><refentrytitle>perldiag</></citerefentry> man page for more
93-
details.
88+
function is wrapped in a subroutine, any named subroutine you place inside
89+
one will be nested. In general, it is far safer to create anonymous
90+
subroutines which you call via a coderef. For more information, see the
91+
entries for <literal>Variable "%s" will not stay shared</literal> and
92+
<literal>Variable "%s" is not available</literal> in the
93+
<citerefentry><refentrytitle>perldiag</></citerefentry> man page, or
94+
search the Internet for <quote>perl nested named subroutine</>.
9495
</para>
9596
</note>
9697

0 commit comments

Comments
 (0)