|
1 | 1 | <!--
|
2 |
| -$Header: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v 2.20 2003/08/31 17:32:19 petere Exp $ |
| 2 | +$Header: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v 2.20.2.1 2010/05/13 16:44:35 adunstan Exp $ |
3 | 3 | -->
|
4 | 4 |
|
5 | 5 | <chapter id="plperl">
|
@@ -259,7 +259,26 @@ CREATE FUNCTION badfunc() RETURNS integer AS '
|
259 | 259 | If the above function was created by a superuser using the language
|
260 | 260 | <literal>plperlu</>, execution would succeed.
|
261 | 261 | </para>
|
262 |
| - </sect1> |
| 262 | + |
| 263 | + <note> |
| 264 | + <para> |
| 265 | + For security reasons, to stop a leak of privileged operations from |
| 266 | + <application>PL/PerlU</> to <application>PL/Perl</>, these two languages |
| 267 | + have to run in separate instances of the Perl interpreter. If your |
| 268 | + Perl installation has been appropriately compiled, this is not a problem. |
| 269 | + However, not all installations are compiled with the requisite flags. |
| 270 | + If <productname>PostgreSQL</> detects that this is the case then it will |
| 271 | + not start a second interpreter, but instead create an error. In |
| 272 | + consequence, in such an installation, you cannot use both |
| 273 | + <application>PL/PerlU</> and <application>PL/Perl</> in the same backend |
| 274 | + process. The remedy for this is to obtain a Perl installation created |
| 275 | + with the appropriate flags, namely either <literal>usemultiplicity</> or |
| 276 | + both <literal>usethreads</> and <literal>useithreads</>. |
| 277 | + For more details,see the <literal>perlembed</> manual page. |
| 278 | + </para> |
| 279 | + </note> |
| 280 | + |
| 281 | +</sect1> |
263 | 282 |
|
264 | 283 | <sect1 id="plperl-missing">
|
265 | 284 | <title>Missing Features</title>
|
|
0 commit comments