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 of a transition relation set, ensuring that the triggers see
   each affected row in a transition relation once and only once.
  </para>

  <para>
   Statement-level triggers on a view are fired only if the action on the
   view is handled by a row-level <literal>INSTEAD OF</literal> trigger.
   If the action is handled by an <literal>INSTEAD</literal> rule, then
   whatever statements are emitted by the rule are executed in place of the
   original statement naming the view, so that the triggers that will be
   fired are those on tables named in the replacement statements.
   Similarly, if the view is automatically updatable, then the action is
   handled by automatically rewriting the statement into an action on the
   view's base table, so that the base table's statement-level triggers are
   the ones that are fired.
  </para>

  <para>
   Modifying a partitioned table or a table with inheritance children fires
   statement-level triggers attached to the explicitly named table, but not
   statement-level triggers for its partitions or child tables.  In contrast,
   row-level triggers are fired on the rows in affected partitions or
   child tables, even if they are not explicitly named in the query.
   If a statement-level trigger has been defined with transition relations
   named by a <literal>REFERENCING</literal> clause, then before and after
   images of rows are visible from all affected partitions or child tables.
   In the case of inheritance children, the row images include only columns
   that are present in the table that the trigger is attached to.
  </para>

  <para>
   Currently, row-level triggers with transition relations cannot be defined
   on partitions or inheritance child tables.  Also, triggers on partitioned
   tables may not be <literal>INSTEAD OF</literal>.
  </para>

  <para>
   Currently, the <literal>OR REPLACE</literal> option is not supported for
   constraint triggers.
  </para>

  <para>
   Replacing an existing trigger within a transaction that has already
   performed updating actions on the trigger's table is not recommended.
   Trigger firing decisions, or portions of firing decisions, that have
   already been made will not be reconsidered, so the effects could be
   surprising.
  </para>

  <para>
   There are a few built-in trigger functions that can be used to
   solve common problems without having to write your own trigger code;
   see <xref linkend="functions-trigger"/>.
  </para>
 </refsect1>

 <refsect1 id="sql-createtrigger-examples">
  <title>Examples</title>

  <para>
   Execute the function <function>check_account_update</function> whenever
   a row of the table <literal>accounts</literal> is about to be updated:

<programlisting>
CREATE TRIGGER check_update
    BEFORE UPDATE ON accounts
    FOR EACH ROW
    EXECUTE FUNCTION check_account_update();
</programlisting>

   Modify that trigger definition to only execute the function if
   column <literal>balance</literal> is specified as a target in