into a statement
    affecting its underlying base table(s), and then the triggers
    that will be fired are the ones attached to the base table(s).
   </para>

   <para>
    The trigger function must be defined before the trigger itself can be
    created.  The trigger function must be declared as a
    function taking no arguments and returning type <literal>trigger</literal>.
    (The trigger function receives its input through a specially-passed
    <structname>TriggerData</structname> structure, not in the form of ordinary function
    arguments.)
   </para>

   <para>
    Once a suitable trigger function has been created, the trigger is
    established with
    <xref linkend="sql-createtrigger"/>.
    The same trigger function can be used for multiple triggers.
   </para>

   <para>
    <productname>PostgreSQL</productname> offers both <firstterm>per-row</firstterm>
    triggers and <firstterm>per-statement</firstterm> triggers.  With a per-row
    trigger, the trigger function
    is invoked once for each row that is affected by the statement
    that fired the trigger. In contrast, a per-statement trigger is
    invoked only once when an appropriate statement is executed,
    regardless of the number of rows affected by that statement. In
    particular, a statement that affects zero rows will still result
    in the execution of any applicable per-statement triggers. These
    two types of triggers are sometimes called <firstterm>row-level</firstterm>
    triggers and <firstterm>statement-level</firstterm> triggers,
    respectively. Triggers on <command>TRUNCATE</command> may only be
    defined at statement level, not per-row.
   </para>

   <para>
    Triggers are also classified according to whether they fire
    <firstterm>before</firstterm>, <firstterm>after</firstterm>, or
    <firstterm>instead of</firstterm> the operation. These are referred to
    as <literal>BEFORE</literal> triggers, <literal>AFTER</literal> triggers, and
    <literal>INSTEAD OF</literal> triggers respectively.
    Statement-level <literal>BEFORE</literal> triggers naturally fire before the
    statement starts to do anything, while statement-level <literal>AFTER</literal>
    triggers fire at the very end of the statement.  These types of
    triggers may be defined on tables, views, or foreign tables.  Row-level
    <literal>BEFORE</literal> triggers fire immediately before a particular row is
    operated on, while row-level <literal>AFTER</literal> triggers fire at the end of
    the statement (but before any statement-level <literal>AFTER</literal> triggers).
    These types of triggers may only be defined on tables and
    foreign tables, not views.
    <literal>INSTEAD OF</literal> triggers may only be
    defined on views, and only at row level; they fire immediately as each
    row in the view is identified as needing to be operated on.
   </para>

   <para>
    The execution of an <literal>AFTER</literal> trigger can be deferred
    to the end of the 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