<quote>clone</quote> trigger to be created on each of its
   existing partitions; and any partitions created or attached later will have
   an identical trigger, too.  If there is a conflictingly-named trigger on a
   child partition already, an error occurs unless <command>CREATE OR REPLACE
   TRIGGER</command> is used, in which case that trigger is replaced with a
   clone trigger.  When a partition is detached from its parent, its clone
   triggers are removed.
  </para>

  <para>
   A column-specific trigger (one defined using the <literal>UPDATE OF
   <replaceable>column_name</replaceable></literal> syntax) will fire when any
   of its columns are listed as targets in the <command>UPDATE</command>
   command's <literal>SET</literal> list.  It is possible for a column's value
   to change even when the trigger is not fired, because changes made to the
   row's contents by <literal>BEFORE UPDATE</literal> triggers are not considered.
   Conversely, a command such as <literal>UPDATE ... SET x = x ...</literal>
   will fire a trigger on column <literal>x</literal>, even though the column's
   value did not change.
  </para>

  <para>
   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.  Note in particular
   that the <literal>NEW</literal> row seen by the condition is the current value,
   as possibly modified by earlier triggers.  Also, a <literal>BEFORE</literal>
   trigger's <literal>WHEN</literal> condition is not allowed to examine the
   system columns of the <literal>NEW</literal> row (such as <literal>ctid</literal>),
   because those won't have been set yet.
  </para>

  <para>
   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.
  </para>

  <para>
   In some cases it is possible for a single SQL command to fire more than
   one kind of trigger.  For instance an <command>INSERT</command> with
   an <literal>ON CONFLICT DO UPDATE</literal> clause may cause both insert and
   update operations, so it will fire both kinds of triggers as needed.
   The transition relations supplied to triggers are
   specific to their event type; thus an <command>INSERT</command> trigger
   will see only the inserted rows, while an <command>UPDATE</command>
   trigger will see only the updated rows.
  </para>

  <para>
   Row updates or deletions caused by foreign-key enforcement actions, such
   as <literal>ON UPDATE CASCADE</literal> or <literal>ON DELETE SET NULL</literal>, are
   treated as part of the SQL command that caused them (note that such
   actions are never deferred).  Relevant triggers on the affected table will
   be fired, so that this provides another way in which an SQL command might
   fire triggers not directly matching its type.  In simple cases, triggers
   that request transition relations will see all changes caused in their
   table by a single original SQL command as a single transition relation.
   However, there are cases in which the presence of an <literal>AFTER ROW</literal>
   trigger that requests transition relations will cause the foreign-key
   enforcement actions triggered by a single SQL command to be split into
   multiple steps, each with its own transition relation(s).  In such cases,
   any statement-level triggers that are present will be fired once per
   creation