<listitem><para><literal>DROP</literal></para></listitem>
      <listitem><para><literal>COMMENT</literal></para></listitem>
      <listitem><para><literal>GRANT</literal></para></listitem>
      <listitem><para><literal>IMPORT FOREIGN SCHEMA</literal></para></listitem>
      <listitem><para><literal>REINDEX</literal></para></listitem>
      <listitem><para><literal>REFRESH MATERIALIZED VIEW</literal></para></listitem>
      <listitem><para><literal>REVOKE</literal></para></listitem>
      <listitem><para><literal>SECURITY LABEL</literal></para></listitem>
     </itemizedlist>
     <literal>ddl_command_start</literal> also occurs just before the
     execution of a <literal>SELECT INTO</literal> command, since this is
     equivalent to <literal>CREATE TABLE AS</literal>.
   </para>

   <para>
     As an exception, this event does not occur for DDL commands targeting
     shared objects:
     <itemizedlist>
      <listitem><para>databases</para></listitem>
      <listitem><para>roles (role definitions and role memberships)</para></listitem>
      <listitem><para>tablespaces</para></listitem>
      <listitem><para>parameter privileges</para></listitem>
      <listitem><para><command>ALTER SYSTEM</command></para></listitem>
     </itemizedlist>
     This event also does not occur for commands targeting event triggers
     themselves.
   </para>

   <para>
     No check whether the affected object exists or doesn't exist is performed
     before the event trigger fires.
   </para>
   </sect2>

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

   <para>
    The <literal>ddl_command_end</literal> event occurs just after the execution of
    the same set of commands as <literal>ddl_command_start</literal>.  To
    obtain more details on the <acronym>DDL</acronym>
    operations that took place, use the set-returning function
    <literal>pg_event_trigger_ddl_commands()</literal> from the
    <literal>ddl_command_end</literal> event trigger code (see
    <xref linkend="functions-event-triggers"/>).  Note that the trigger fires
    after the actions have taken place (but before the transaction commits),
    and thus the system catalogs can be read as already changed.
   </para>
   </sect2>

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

   <para>
    The <literal>sql_drop</literal> event occurs just before the
    <literal>ddl_command_end</literal> event trigger for any operation that drops
    database objects.  Note that besides the obvious <literal>DROP</literal>
    commands, some <literal>ALTER</literal> commands can also trigger an
    <literal>sql_drop</literal> event.
   </para>

   <para>
    To list the objects that have been dropped, use the
    set-returning function <literal>pg_event_trigger_dropped_objects()</literal> from the
    <literal>sql_drop</literal> event trigger code (see
    <xref linkend="functions-event-triggers"/>). Note that
    the trigger is executed after the objects have been 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