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 inherits the
      schema of its table.  For a constraint trigger, this is also the name to
      use when modifying the trigger's behavior using
      <command>SET CONSTRAINTS</command>.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>BEFORE</literal></term>
    <term><literal>AFTER</literal></term>
    <term><literal>INSTEAD OF</literal></term>
    <listitem>
     <para>
      Determines whether the function is called before, after, or instead of
      the event.  A constraint trigger can only be specified as
      <literal>AFTER</literal>.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">event</replaceable></term>
    <listitem>
     <para>
      One of <literal>INSERT</literal>, <literal>UPDATE</literal>,
      <literal>DELETE</literal>, or <literal>TRUNCATE</literal>;
      this specifies the event that will fire the trigger. Multiple
      events can be specified using <literal>OR</literal>, except when
      transition relations are requested.
     </para>

     <para>
      For <literal>UPDATE</literal> events, it is possible to
      specify a list of columns using this syntax:
<synopsis>
UPDATE OF <replaceable>column_name1</replaceable> [, <replaceable>column_name2</replaceable> ... ]
</synopsis>
      The trigger will only fire if at least one of the listed columns
      is mentioned as a target of the <command>UPDATE</command> command
      or if one of the listed columns is a generated column that depends on a
      column that is the target of the <command>UPDATE</command>.
     </para>

     <para>
      <literal>INSTEAD OF UPDATE</literal> events do not allow a list of columns.
      A column list cannot be specified when requesting transition relations,
      either.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">table_name</replaceable></term>
    <listitem>
     <para>
      The name (optionally schema-qualified) of the table, view, or foreign
      table the trigger is for.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">referenced_table_name</replaceable></term>
    <listitem>
     <para>
      The (possibly schema-qualified) name of another table referenced by the
      constraint.  This option is used for foreign-key constraints and is not
      recommended for general use.  This can only be specified for
      constraint triggers.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>DEFERRABLE</literal></term>
    <term><literal>NOT DEFERRABLE</literal></term>
    <term><literal>INITIALLY IMMEDIATE</literal></term>
    <term><literal>INITIALLY DEFERRED</literal></term>
    <listitem>
     <para>
      The default timing of the trigger.
      See the <xref linkend="sql-createtable"/> documentation for details of
      these constraint options.  This can only be specified