Home Explore Blog CI



postgresql

6th chunk of `doc/src/sgml/ref/create_trigger.sgml`
a5de4c67308f74cd26f52956fb704319438d71f3916771610000000100000fab
 the <literal>WHEN</literal>
      condition can refer to columns of the old and/or new row values
      by writing <literal>OLD.<replaceable
      class="parameter">column_name</replaceable></literal> or
      <literal>NEW.<replaceable
      class="parameter">column_name</replaceable></literal> respectively.
      Of course, <literal>INSERT</literal> triggers cannot refer to <literal>OLD</literal>
      and <literal>DELETE</literal> triggers cannot refer to <literal>NEW</literal>.
     </para>

     <para><literal>INSTEAD OF</literal> triggers do not support <literal>WHEN</literal>
      conditions.
     </para>

     <para>
      Currently, <literal>WHEN</literal> expressions cannot contain
      subqueries.
     </para>

     <para>
      Note that for constraint triggers, evaluation of the <literal>WHEN</literal>
      condition is not deferred, but occurs immediately after the row update
      operation is performed. If the condition does not evaluate to true then
      the trigger is not queued for deferred execution.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">function_name</replaceable></term>
    <listitem>
     <para>
      A user-supplied function that is declared as taking no arguments
      and returning type <literal>trigger</literal>, which is executed when
      the trigger fires.
     </para>

     <para>
      In the syntax of <literal>CREATE TRIGGER</literal>, the keywords
      <literal>FUNCTION</literal> and <literal>PROCEDURE</literal> are
      equivalent, but the referenced function must in any case be a function,
      not a procedure.  The use of the keyword <literal>PROCEDURE</literal>
      here is historical and deprecated.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">arguments</replaceable></term>
    <listitem>
     <para>
      An optional comma-separated list of arguments to be provided to
      the function when the trigger is executed.  The arguments are
      literal string constants.  Simple names and numeric constants
      can be written here, too, but they will all be converted to
      strings.  Please check the description of the implementation
      language of the trigger function to find out how these arguments
      can be accessed within the function; it might be different from
      normal function arguments.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </refsect1>

 <refsect1 id="sql-createtrigger-notes">
  <title>Notes</title>

  <para>
   To create or replace a trigger on a table, the user must have the
   <literal>TRIGGER</literal> privilege on the table.  The user must
   also have <literal>EXECUTE</literal> privilege on the trigger function.
  </para>

  <para>
   Use <link linkend="sql-droptrigger"><command>DROP TRIGGER</command></link> to remove a trigger.
  </para>

  <para>
   Creating a row-level trigger on a partitioned table will cause an
   identical <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

Title: CREATE TRIGGER Parameters (Continued) and Notes
Summary
This section continues describing CREATE TRIGGER parameters, focusing on the function_name (the user-supplied function executed when the trigger fires) and arguments (optional list of arguments provided to the function). It also covers important notes about creating, dropping, and managing triggers. The user needs TRIGGER and EXECUTE privileges to create a trigger. DROP TRIGGER removes a trigger. Creating row-level triggers on partitioned tables creates clone triggers on partitions. Column-specific triggers fire when specified columns are targeted in an UPDATE command's SET list.