deleted from the
    system catalogs, so it's not possible to look them up anymore.
   </para>
   </sect2>

   <sect2 id="event-trigger-table_rewrite">
    <title>table_rewrite</title>

   <para>
    The <literal>table_rewrite</literal> event occurs just before a table is
    rewritten by some actions of the commands <literal>ALTER TABLE</literal> and
    <literal>ALTER TYPE</literal>.  While other
    control statements are available to rewrite a table,
    like <literal>CLUSTER</literal> and <literal>VACUUM</literal>,
    the <literal>table_rewrite</literal> event is not triggered by them.
    To find the OID of the table that was rewritten, use the function
    <literal>pg_event_trigger_table_rewrite_oid()</literal>, to discover the
    reason(s) for the rewrite, use the function
    <literal>pg_event_trigger_table_rewrite_reason()</literal> (see <xref
    linkend="functions-event-triggers"/>).
   </para>
   </sect2>

   <sect2 id="event-trigger-aborted-transactions">
    <title>Event Triggers in Aborted Transactions</title>

   <para>
     Event triggers (like other functions) cannot be executed in an aborted
     transaction.  Thus, if a DDL command fails with an error, any associated
     <literal>ddl_command_end</literal> triggers will not be executed.  Conversely,
     if a <literal>ddl_command_start</literal> trigger fails with an error, no
     further event triggers will fire, and no attempt will be made to execute
     the command itself.  Similarly, if a <literal>ddl_command_end</literal> trigger
     fails with an error, the effects of the DDL statement will be rolled
     back, just as they would be in any other case where the containing
     transaction aborts.
   </para>
   </sect2>

   <sect2 id="event-trigger-creating">
    <title>Creating Event Triggers</title>

   <para>
     Event triggers are created using the command <xref linkend="sql-createeventtrigger"/>.
     In order to create an event trigger, you must first create a function with
     the special return type <literal>event_trigger</literal>.  This function
     need not (and may not) return a value; the return type serves merely as
     a signal that the function is to be invoked as an event trigger.
   </para>

   <para>
     If more than one event trigger is defined for a particular event, they will
     fire in alphabetical order by trigger name.
   </para>

   <para>
     A trigger definition can also specify a <literal>WHEN</literal>
     condition so that, for example, a <literal>ddl_command_start</literal>
     trigger can be fired only for particular commands which the user wishes
     to intercept. A common use of such triggers is to restrict the range of
     DDL operations which users may perform.
   </para>
   </sect2>
  </sect1>

  <sect1 id="event-trigger-interface">
   <title>Writing Event Trigger Functions in C</title>

   <indexterm zone="event-trigger-interface">
    <primary>event trigger</primary>
    <secondary>in C</secondary>
   </indexterm>

   <para>
    This section describes the low-level details of the interface to an
    event trigger function. This information is only needed when writing
    event trigger functions in C. If you are using a higher-level language
    then these details are handled for you. In most cases you should
    consider using a procedural language before writing your event triggers
    in C. The documentation of each procedural language explains how to
    write an event trigger in that language.
   </para>

   <para>
    Event trigger functions must use the <quote>version 1</quote> function
    manager interface.
   </para>

   <para>
    When a function is called by the event trigger manager, it is not passed
    any normal arguments, but it is passed a <quote>context</quote> pointer
    pointing to a <structname>EventTriggerData</structname> structure. C functions can
    check whether they were called from the event trigger manager or not by
    executing the macro:
<programlisting>
CALLED_AS_EVENT_TRIGGER(fcinfo)