FUNCTION use_quote(TEXT) RETURNS text AS $$
    my $text_to_quote = shift;
    my $qfunc = $_SHARED{myquote};
    return &$qfunc($text_to_quote);
$$ LANGUAGE plperl;
</programlisting>

   (You could have replaced the above with the one-liner
   <literal>return $_SHARED{myquote}-&gt;($_[0]);</literal>
   at the expense of readability.)
  </para>

  <para>
   For security reasons, PL/Perl executes functions called by any one SQL role
   in a separate Perl interpreter for that role.  This prevents accidental or
   malicious interference by one user with the behavior of another user's
   PL/Perl functions.  Each such interpreter has its own value of the
   <varname>%_SHARED</varname> variable and other global state.  Thus, two
   PL/Perl functions will share the same value of <varname>%_SHARED</varname>
   if and only if they are executed by the same SQL role.  In an application
   wherein a single session executes code under multiple SQL roles (via
   <literal>SECURITY DEFINER</literal> functions, use of <command>SET ROLE</command>, etc.)
   you may need to take explicit steps to ensure that PL/Perl functions can
   share data via <varname>%_SHARED</varname>.  To do that, make sure that
   functions that should communicate are owned by the same user, and mark
   them <literal>SECURITY DEFINER</literal>.  You must of course take care that
   such functions can't be used to do anything unintended.
  </para>
 </sect1>

 <sect1 id="plperl-trusted">
  <title>Trusted and Untrusted PL/Perl</title>

  <indexterm zone="plperl-trusted">
   <primary>trusted</primary>
   <secondary>PL/Perl</secondary>
  </indexterm>

  <para>
   Normally, PL/Perl is installed as a <quote>trusted</quote> programming
   language named <literal>plperl</literal>.  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,
   <literal>require</literal>, and <literal>use</literal> (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.
  </para>

  <warning>
   <para>
    Trusted PL/Perl relies on the Perl <literal>Opcode</literal> module to
    preserve security.
    Perl
    <ulink url="https://perldoc.perl.org/Opcode#WARNING">documents</ulink>
    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 <literal>REVOKE USAGE ON LANGUAGE plperl FROM
    PUBLIC</literal>.
   </para>
  </warning>

  <para>
   Here is an example of a function that will not work because file
   system operations are not allowed for security reasons:
<programlisting>
CREATE FUNCTION badfunc() RETURNS integer AS $$
    my $tmpfile = "/tmp/badfile";
    open my $fh, '&gt;', $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;
</programlisting>
    The creation of this function will fail as its use of a forbidden
    operation will be caught by the validator.
  </para>

  <para>
   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
   <quote>untrusted</quote> language (usually called
   <application>PL/PerlU</application><indexterm><primary>PL/PerlU</primary></indexterm>).
   In this case the full Perl language is available.  When installing the
   language, the language name <literal>plperlu</literal> will select
   the untrusted PL/Perl variant.
  </para>

  <para>
   The