align="center"><command>INSERT</command>/<command>UPDATE</command>/<command>DELETE</command></entry>
      <entry align="center">Views</entry>
      <entry align="center">&mdash;</entry>
     </row>
     <row>
      <entry align="center"><command>TRUNCATE</command></entry>
      <entry align="center">&mdash;</entry>
      <entry align="center">&mdash;</entry>
     </row>
    </tbody>
   </tgroup>
  </informaltable>

  <para>
   Also, a trigger definition can specify a Boolean <literal>WHEN</literal>
   condition, which will be tested to see whether the trigger should
   be fired.  In row-level triggers the <literal>WHEN</literal> condition can
   examine the old and/or new values of columns of the row.  Statement-level
   triggers can also have <literal>WHEN</literal> conditions, although the feature
   is not so useful for them since the condition cannot refer to any values
   in the table.
  </para>

  <para>
   If multiple triggers of the same kind are defined for the same event,
   they will be fired in alphabetical order by name.
  </para>

  <para>
   When the <literal>CONSTRAINT</literal> option is specified, this command creates a
   <firstterm>constraint trigger</firstterm>.<indexterm><primary>trigger</primary>
   <secondary>constraint trigger</secondary></indexterm>
   This is the same as a regular trigger
   except that the timing of the trigger firing can be adjusted using
   <link linkend="sql-set-constraints"><command>SET CONSTRAINTS</command></link>.
   Constraint triggers must be <literal>AFTER ROW</literal> triggers on plain
   tables (not foreign tables).  They
   can be fired either at the end of the statement causing the triggering
   event, or at the end of the containing transaction; in the latter case they
   are said to be <firstterm>deferred</firstterm>.  A pending deferred-trigger firing
   can also be forced to happen immediately by using <command>SET
   CONSTRAINTS</command>.  Constraint triggers are expected to raise an exception
   when the constraints they implement are violated.
  </para>

  <para>
   The <literal>REFERENCING</literal> option enables collection
   of <firstterm>transition relations</firstterm>, which are row sets that include all
   of the rows inserted, deleted, or modified by the current SQL statement.
   This feature lets the trigger see a global view of what the statement did,
   not just one row at a time.  This option is only allowed for
   an <literal>AFTER</literal> trigger that is not a constraint trigger; also, if
   the trigger is an <literal>UPDATE</literal> trigger, it must not specify
   a <replaceable class="parameter">column_name</replaceable> list.
   <literal>OLD TABLE</literal> may only be specified once, and only for a trigger
   that can fire on <literal>UPDATE</literal> or <literal>DELETE</literal>; it creates a
   transition relation containing the <firstterm>before-images</firstterm> of all rows
   updated or deleted by the statement.
   Similarly, <literal>NEW TABLE</literal> may only be specified once, and only for
   a trigger that can fire on <literal>UPDATE</literal> or <literal>INSERT</literal>;
   it creates a transition relation containing the <firstterm>after-images</firstterm>
   of all rows updated or inserted by the statement.
  </para>

  <para>
   <command>SELECT</command> does not modify any rows so you cannot
   create <command>SELECT</command> triggers.  Rules and views may provide
   workable solutions to problems that seem to need <command>SELECT</command>
   triggers.
  </para>

  <para>
   Refer to <xref linkend="triggers"/> for more information about triggers.
  </para>
 </refsect1>

 <refsect1>
  <title>Parameters</title>

  <variablelist>
   <varlistentry>
    <term><replaceable class="parameter">name</replaceable></term>
    <listitem>
     <para>
      The name to give the new trigger.  This must be distinct from
      the name of any other trigger for the same table.
      The name cannot be schema-qualified &mdash; the trigger