trigger is fired.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </para>

  <para>
   The return value of the trigger function is ignored.
  </para>

  <para>
   Here is an example of an event trigger function, illustrating some of the
   above:
<programlisting>
CREATE OR REPLACE FUNCTION perlsnitch() RETURNS event_trigger AS $$
  elog(NOTICE, "perlsnitch: " . $_TD->{event} . " " . $_TD->{tag} . " ");
$$ LANGUAGE plperl;

CREATE EVENT TRIGGER perl_a_snitch
    ON ddl_command_start
    EXECUTE FUNCTION perlsnitch();
</programlisting>
  </para>
 </sect1>

 <sect1 id="plperl-under-the-hood">
  <title>PL/Perl Under the Hood</title>

 <sect2 id="plperl-config">
  <title>Configuration</title>

  <para>
  This section lists configuration parameters that affect <application>PL/Perl</application>.
  </para>

  <variablelist>

     <varlistentry id="guc-plperl-on-init" xreflabel="plperl.on_init">
      <term>
       <varname>plperl.on_init</varname> (<type>string</type>)
      <indexterm>
       <primary><varname>plperl.on_init</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Specifies Perl code to be executed when a Perl interpreter is first
        initialized, before it is specialized for use by <literal>plperl</literal> or
        <literal>plperlu</literal>.
        The SPI functions are not available when this code is executed.
        If the code fails with an error it will abort the initialization of
        the interpreter and propagate out to the calling query, causing the
        current transaction or subtransaction to be aborted.
       </para>
       <para>
       The Perl code is limited to a single string. Longer code can be placed
       into a module and loaded by the <literal>on_init</literal> string.
       Examples:
<programlisting>
plperl.on_init = 'require "plperlinit.pl"'
plperl.on_init = 'use lib "/my/app"; use MyApp::PgInit;'
</programlisting>
       </para>
       <para>
       Any modules loaded by <literal>plperl.on_init</literal>, either directly or
       indirectly, will be available for use by <literal>plperl</literal>.  This may
       create a security risk. To see what modules have been loaded you can use:
<programlisting>
DO 'elog(WARNING, join ", ", sort keys %INC)' LANGUAGE plperl;
</programlisting>
       </para>
       <para>
        Initialization will happen in the postmaster if the <literal>plperl</literal> library is
        included in <xref linkend="guc-shared-preload-libraries"/>, in which
        case extra consideration should be given to the risk of destabilizing
        the postmaster.  The principal reason for making use of this feature
        is that Perl modules loaded by <literal>plperl.on_init</literal> need be
        loaded only at postmaster start, and will be instantly available
        without loading overhead in individual database sessions.  However,
        keep in mind that the overhead is avoided only for the first Perl
        interpreter used by a database session &mdash; either PL/PerlU, or
        PL/Perl for the first SQL role that calls a PL/Perl function.  Any
        additional Perl interpreters created in a database session will have
        to execute <literal>plperl.on_init</literal> afresh.  Also, on Windows there
        will be no savings whatsoever from preloading, since the Perl
        interpreter created in the postmaster process does not propagate to
        child processes.
       </para>
       <para>
       This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-plperl-on-plperl-init" xreflabel="plperl.on_plperl_init">
      <term>
       <varname>plperl.on_plperl_init</varname> (<type>string</type>)
       <indexterm>
        <primary><varname>plperl.on_plperl_init</varname> configuration parameter</primary>
       </indexterm>