</para>

   <para>
    If more than one trigger is defined for the same event on the same
    relation, the triggers will be fired in alphabetical order by
    trigger name.  In the case of <literal>BEFORE</literal> and
    <literal>INSTEAD OF</literal> triggers, the possibly-modified row returned by
    each trigger becomes the input to the next trigger.  If any
    <literal>BEFORE</literal> or <literal>INSTEAD OF</literal> trigger returns
    <symbol>NULL</symbol>, the operation is abandoned for that row and subsequent
    triggers are not fired (for that row).
   </para>

   <para>
    A trigger definition can also 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.)  In a <literal>BEFORE</literal> trigger, the
    <literal>WHEN</literal>
    condition is evaluated just before the function is or would be executed,
    so using <literal>WHEN</literal> is not materially different from testing the
    same condition at the beginning of the trigger function.  However, in
    an <literal>AFTER</literal> trigger, the <literal>WHEN</literal> condition is evaluated
    just after the row update occurs, and it determines whether an event is
    queued to fire the trigger at the end of statement.  So when an
    <literal>AFTER</literal> trigger's
    <literal>WHEN</literal> condition does not return true, it is not necessary
    to queue an event nor to re-fetch the row at end of statement.  This
    can result in significant speedups in statements that modify many
    rows, if the trigger only needs to be fired for a few of the rows.
    <literal>INSTEAD OF</literal> triggers do not support
    <literal>WHEN</literal> conditions.
   </para>

   <para>
    Typically, row-level <literal>BEFORE</literal> triggers are used for checking or
    modifying the data that will be inserted or updated.  For example,
    a <literal>BEFORE</literal> trigger might be used to insert the current time into a
    <type>timestamp</type> column, or to check that two elements of the row are
    consistent. Row-level <literal>AFTER</literal> triggers are most sensibly
    used to propagate the updates to other tables, or make consistency
    checks against other tables.  The reason for this division of labor is
    that an <literal>AFTER</literal> trigger can be certain it is seeing the final
    value of the row, while a <literal>BEFORE</literal> trigger cannot; there might
    be other <literal>BEFORE</literal> triggers firing after it.  If you have no
    specific reason to make a trigger <literal>BEFORE</literal> or
    <literal>AFTER</literal>, the <literal>BEFORE</literal> case is more efficient, since
    the information about
    the operation doesn't have to be saved until end of statement.
   </para>

   <para>
    If a trigger function executes SQL commands then these
    commands might fire triggers again. This is known as cascading
    triggers.  There is no direct limitation on the number of cascade
    levels.  It is possible for cascades to cause a recursive invocation
    of the same trigger; for example, an <command>INSERT</command>
    trigger might execute a command that inserts an additional row
    into the same table, causing the <command>INSERT</command> trigger
    to be fired again.  It is the trigger programmer's responsibility
    to avoid infinite recursion in such scenarios.
   </para>

   <para>
    If a foreign key constraint specifies referential actions (that
    is, cascading updates or deletes), those actions are performed via
    ordinary SQL <command>UPDATE</command> or <command>DELETE</command>
    commands on the referencing table.
    In particular, any triggers that exist on the referencing