transaction, rather than the end of the statement,
    if it was defined as a <firstterm>constraint trigger</firstterm>.
    In all cases, a trigger is executed as part of the same transaction as
    the statement that triggered it, so if either the statement or the
    trigger causes an error, the effects of both will be rolled back.
    Also, the trigger will always run in the security context of the role
    that executed the statement that caused the trigger to fire, unless
    the trigger function is defined as <literal>SECURITY DEFINER</literal>,
    in which case it will run as the function owner.
   </para>

   <para>
    If an <command>INSERT</command> contains an <literal>ON CONFLICT
    DO UPDATE</literal> clause, it is possible for row-level
    <literal>BEFORE</literal> <command>INSERT</command> and then
    <literal>BEFORE</literal> <command>UPDATE</command> triggers
    to be executed on triggered rows.  Such interactions can be
    complex if the triggers are not idempotent because change made by
    <literal>BEFORE</literal> <command>INSERT</command> triggers will be
    seen by <literal>BEFORE</literal> <command>UPDATE</command> triggers,
    including changes to <varname>EXCLUDED</varname> columns.
   </para>

   <para>
    Note that statement-level
    <command>UPDATE</command> triggers are executed when <literal>ON
    CONFLICT DO UPDATE</literal> is specified, regardless of whether or not
    any rows were affected by the <command>UPDATE</command> (and
    regardless of whether the alternative <command>UPDATE</command>
    path was ever taken).  An <command>INSERT</command> with an
    <literal>ON CONFLICT DO UPDATE</literal> clause will execute
    statement-level <literal>BEFORE</literal> <command>INSERT</command>
    triggers first, then statement-level <literal>BEFORE</literal>
    <command>UPDATE</command> triggers, followed by statement-level
    <literal>AFTER</literal> <command>UPDATE</command> triggers and finally
    statement-level <literal>AFTER</literal> <command>INSERT</command>
    triggers.
   </para>

   <para>
    A statement that targets a parent table in an inheritance or partitioning
    hierarchy does not cause the statement-level triggers of affected child
    tables to be fired; only the parent table's statement-level triggers are
    fired.  However, row-level triggers of any affected child tables will be
    fired.
   </para>

   <para>
    If an <command>UPDATE</command> on a partitioned table causes a row to move
    to another partition, it will be performed as a <command>DELETE</command>
    from the original partition followed by an <command>INSERT</command> into
    the new partition. In this case, all row-level <literal>BEFORE</literal>
    <command>UPDATE</command> triggers and all row-level
    <literal>BEFORE</literal> <command>DELETE</command> triggers are fired on
    the original partition. Then all row-level <literal>BEFORE</literal>
    <command>INSERT</command> triggers are fired on the destination partition.
    The possibility of surprising outcomes should be considered when all these
    triggers affect the row being moved. As far as <literal>AFTER ROW</literal>
    triggers are concerned, <literal>AFTER</literal> <command>DELETE</command>
    and <literal>AFTER</literal> <command>INSERT</command> triggers are
    applied; but <literal>AFTER</literal> <command>UPDATE</command> triggers
    are not applied because the <command>UPDATE</command> has been converted to
    a <command>DELETE</command> and an <command>INSERT</command>. As far as
    statement-level triggers are concerned, none of the
    <command>DELETE</command> or <command>INSERT</command> triggers are fired,
    even if row movement occurs; only the <command>UPDATE</command> triggers
    defined on the target table used in the <command>UPDATE</command> statement
    will be fired.
   </para>

   <para>
    No separate triggers are defined for <command>MERGE</command>. Instead,
    statement-level or