*** pgsql/doc/src/sgml/plperl.sgml	2005/01/17 17:29:49	2.37
--- pgsql/doc/src/sgml/plperl.sgml	2010/05/13 16:44:03	2.37.4.1
***************
*** 1,5 ****
  <!--
! $PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.36 2005/01/17 03:04:17 momjian Exp $
  -->
  
   <chapter id="plperl">
--- 1,5 ----
  <!--
! $PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.37 2005/01/17 17:29:49 momjian Exp $
  -->
  
   <chapter id="plperl">
*************** $$ LANGUAGE plperl;
*** 458,464 ****
     If the above function was created by a superuser using the language
     <literal>plperlu</>, execution would succeed.
    </para>
!  </sect1>
  
   <sect1 id="plperl-triggers">
    <title>PL/Perl Triggers</title>
--- 458,483 ----
     If the above function was created by a superuser using the language
     <literal>plperlu</>, execution would succeed.
    </para>
! 
!   <note>
!     <para>
!           For security reasons, to stop a leak of privileged operations from
!       <application>PL/PerlU</> to <application>PL/Perl</>, these two languages
!           have to run in separate instances of the Perl interpreter. If your
!           Perl installation has been appropriately compiled, this is not a problem.
!           However, not all installations are compiled with the requisite flags.
!           If <productname>PostgreSQL</> detects that this is the case then it will
!           not start a second interpreter, but instead create an error. In
!           consequence, in such an installation, you cannot use both 
!           <application>PL/PerlU</> and <application>PL/Perl</> in the same backend
!           process. The remedy for this is to obtain a Perl installation created
!           with the appropriate flags, namely either <literal>usemultiplicity</> or
!           both <literal>usethreads</> and <literal>useithreads</>. 
!           For more details,see the <literal>perlembed</> manual page.
!     </para>
!   </note>
!   
! </sect1>
  
   <sect1 id="plperl-triggers">
    <title>PL/Perl Triggers</title>