@@ -1,5 +1,5 @@ <
8000
/code>
|
1 | 1 | <!--
|
2 |
| -$PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.37 2005/01/17 17:29:49 momjian Exp $ |
| 2 | +$PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.37.4.1 2010/05/13 16:44:03 adunstan Exp $ |
3 | 3 | -->
|
4 | 4 |
|
5 | 5 | <chapter id="plperl">
|
@@ -458,7 +458,26 @@ $$ LANGUAGE plperl;
|
458 | 458 | If the above function was created by a superuser using the language
|
459 | 459 | <literal>plperlu</>, execution would succeed.
|
460 | 460 | </para>
|
461 |
| - </sect1> |
| 461 | + |
| 462 | + <note> |
| 463 | + <para> |
| 464 | + For security reasons, to stop a leak of privileged operations from |
| 465 | + <application>PL/PerlU</> to <application>PL/Perl</>, these two languages |
| 466 | + have to run in separate instances of the Perl interpreter. If your |
| 467 | + Perl installation has been appropriately compiled, this is not a problem. |
| 468 | + However, not all installations are compiled with the requisite flags. |
| 469 | + If <productname>PostgreSQL</> detects that this is the case then it will |
| 470 | + not start a second interpreter, but instead create an error. In |
| 471 | + consequence, in such an installation, you cannot use both |
| 472 | + <application>PL/PerlU</> and <application>PL/Perl</> in the same backend |
| 473 | + process. The remedy for this is to obtain a Perl installation created |
| 474 | + with the appropriate flags, namely either <literal>usemultiplicity</> or |
| 475 | + both <literal>usethreads</> and <literal>useithreads</>. |
| 476 | + For more details,see the <literal>perlembed</> manual page. |
| 477 | + </para> |
| 478 | + </note> |
| 479 | + |
| 480 | +</sect1> |
462 | 481 |
|
463 | 482 | <sect1 id="plperl-triggers">
|
464 | 483 | <title>PL/Perl Triggers</title>
|
|
0 commit comments