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;
</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 writer of a <application>PL/PerlU</application> 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.
  </para>

  <para>
   If the above function was created by a superuser using the language
   <literal>plperlu</literal>, execution would succeed.
  </para>

  <para>
   In the same way, anonymous code blocks written in Perl can use
   restricted operations if the language is specified as
   <literal>plperlu</literal> rather than <literal>plperl</literal>, but the caller
   must be a superuser.
  </para>

  <note>
   <para>
    While <application>PL/Perl</application> functions run in a separate Perl
    interpreter for each SQL role, all <application>PL/PerlU</application> functions
    executed in a given session run in a single Perl interpreter (which is
    not any of the ones used for <application>PL/Perl</application> functions).
    This allows <application>PL/PerlU</application> functions to share data freely,
    but no communication can occur between <application>PL/Perl</application> and
    <application>PL/PerlU</application> functions.
   </para>
  </note>

  <note>
   <para>
    Perl cannot support multiple interpreters within one process unless
    it was built with the appropriate flags, namely either
    <literal>usemultiplicity</literal> or <literal>useithreads</literal>.
    (<literal>usemultiplicity</literal> is preferred unless you actually need
    to use threads.  For more details, see the
    <citerefentry><refentrytitle>perlembed</refentrytitle></citerefentry> man page.)
    If <application>PL/Perl</application> 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
    <application>PL/PerlU</application> functions, or <application>PL/Perl</application> functions
    that are all called by the same SQL role.
   </para>
  </note>

 </sect1>

 <sect1 id="plperl-triggers">
  <title>PL/Perl Triggers</title>

  <para>
   PL/Perl can be used to write trigger functions.  In a trigger function,
   the hash reference <varname>$_TD</varname> contains information about the
   current trigger event. <varname>$_TD</varname> is a global variable,
   which gets a separate local value for each invocation of the trigger.
   The fields of the <varname>$_TD</varname> hash reference are:

   <variablelist>
    <varlistentry>
     <term><literal>$_TD-&gt;{new}{foo}</literal></term>
     <listitem>
      <para>
       <literal>NEW</literal> value of column <literal>foo</literal>
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>$_TD-&gt;{old}{foo}</literal></term>
     <listitem>
      <para>
       <literal>OLD</literal> value of column