|
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 $ --> |
2 | 2 |
|
3 | 3 | <chapter id="plperl"> |
4 | 4 | <title>PL/Perl - Perl Procedural Language</title> |
@@ -85,12 +85,13 @@ $$ LANGUAGE plperl; |
85 | 85 | <para> |
86 | 86 | The use of named nested subroutines is dangerous in Perl, especially if |
87 | 87 | 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</>. |
94 | 95 | </para> |
95 | 96 | </note> |
96 | 97 |
|
|