43.5. Trusted and Untrusted PL/Perl
  Normally, PL/Perl is installed as a
  
   "
   
    trusted
   
   "
  
  programming
   language named
  
   plperl
  
  .  In this setup, certain Perl
   operations are disabled to preserve security.  In general, the
   operations that are restricted are those that interact with the
   environment. This includes file handle operations,
  
   require
  
  , and
  
   use
  
  (for
   external modules).  There is no way to access internals of the
   database server process or to gain OS-level access with the
   permissions of the server process,
   as a C function can do.  Thus, any unprivileged database user can
   be permitted to use this language.
 
Warning
   Trusted PL/Perl relies on the Perl
   
    Opcode
   
   module to
    preserve security.
    Perl
   
    documents
   
   that the module is not effective for the trusted PL/Perl use case.  If
    your security needs are incompatible with the uncertainty in that warning,
    consider executing
   
    REVOKE USAGE ON LANGUAGE plperl FROM
    PUBLIC
   
   .
  
Here is an example of a function that will not work because file system operations are not allowed for security reasons:
CREATE FUNCTION badfunc() RETURNS integer AS $$
    my $tmpfile = "/tmp/badfile";
    open my $fh, '>', $tmpfile
        or elog(ERROR, qq{could not open the file "$tmpfile": $!});
    print $fh "Testing writing to a file\n";
    close $fh or elog(ERROR, qq{could not close the file "$tmpfile": $!});
    return 1;
$$ LANGUAGE plperl;
 The creation of this function will fail as its use of a forbidden operation will be caught by the validator.
  Sometimes it is desirable to write Perl functions that are not
   restricted.  For example, one might want a Perl function that sends
   mail.  To handle these cases, PL/Perl can also be installed as an
  
   "
   
    untrusted
   
   "
  
  language (usually called
  
   PL/PerlU
  
  
  
  ).
   In this case the full Perl language is available.  When installing the
   language, the language name
  
   plperlu
  
  will select
   the untrusted PL/Perl variant.
 
The writer of a PL/PerlU function must take care that the function cannot be used to do anything unwanted, since it will be able to do anything that could be done by a user logged in as the database administrator. Note that the database system allows only database superusers to create functions in untrusted languages.
  If the above function was created by a superuser using the language
  
   plperlu
  
  , execution would succeed.
 
  In the same way, anonymous code blocks written in Perl can use
   restricted operations if the language is specified as
  
   plperlu
  
  rather than
  
   plperl
  
  , but the caller
   must be a superuser.
 
Note
While PL/Perl functions run in a separate Perl interpreter for each SQL role, all PL/PerlU functions executed in a given session run in a single Perl interpreter (which is not any of the ones used for PL/Perl functions). This allows PL/PerlU functions to share data freely, but no communication can occur between PL/Perl and PL/PerlU functions.
Note
   Perl cannot support multiple interpreters within one process unless
    it was built with the appropriate flags, namely either
   
    usemultiplicity
   
   or
   
    useithreads
   
   .
    (
   
    usemultiplicity
   
   is preferred unless you actually need
    to use threads.  For more details, see the
   
    
     perlembed
    
   
   man page.)
    If
   
    PL/Perl
   
   is used with a copy of Perl that was not built
    this way, then it is only possible to have one Perl interpreter per
    session, and so any one session can only execute either
   
    PL/PerlU
   
   functions, or
   
    PL/Perl
   
   functions
    that are all called by the same SQL role.