these types of rules at
  all, notably including <literal>WITH</literal> clauses in the original query and
  multiple-assignment sub-<literal>SELECT</literal>s in the <literal>SET</literal> list
  of <command>UPDATE</command> queries.  This is because copying these constructs
  into a rule query would result in multiple evaluations of the sub-query,
  contrary to the express intent of the query's author.
 </para>
</caution>

<sect2 id="rules-update-how">
<title>How Update Rules Work</title>

<para>
    Keep the syntax:

<programlisting>
CREATE [ OR REPLACE ] RULE <replaceable class="parameter">name</replaceable> AS ON <replaceable class="parameter">event</replaceable>
    TO <replaceable class="parameter">table</replaceable> [ WHERE <replaceable class="parameter">condition</replaceable> ]
    DO [ ALSO | INSTEAD ] { NOTHING | <replaceable class="parameter">command</replaceable> | ( <replaceable class="parameter">command</replaceable> ; <replaceable class="parameter">command</replaceable> ... ) }
</programlisting>

    in mind.
    In the following, <firstterm>update rules</firstterm> means rules that are defined
    on <command>INSERT</command>, <command>UPDATE</command>, or <command>DELETE</command>.
</para>

<para>
    Update rules get applied by the rule system when the result
    relation and the command type of a query tree are equal to the
    object and event given in the <command>CREATE RULE</command> command.
    For update rules, the rule system creates a list of query trees.
    Initially the query-tree list is empty.
    There can be zero (<literal>NOTHING</literal> key word), one, or multiple actions.
    To simplify, we will look at a rule with one action. This rule
    can have a qualification or not and it can be <literal>INSTEAD</literal> or
    <literal>ALSO</literal> (the default).
</para>

<para>
    What is a rule qualification? It is a restriction that tells
    when the actions of the rule should be done and when not. This
    qualification can only reference the pseudorelations <literal>NEW</literal> and/or <literal>OLD</literal>,
    which basically represent the relation that was given as object (but with a
    special meaning).
</para>

   <para>
    So we have three cases that produce the following query trees for
    a one-action rule.

    <variablelist>
     <varlistentry>
      <term>No qualification, with either <literal>ALSO</literal> or
      <literal>INSTEAD</literal></term>
      <listitem>
       <para>
        the query tree from the rule action with the original query
        tree's qualification added
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>Qualification given and <literal>ALSO</literal></term>
      <listitem>
       <para>
        the query tree from the rule action with the rule
        qualification and the original query tree's qualification
        added
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>Qualification given and <literal>INSTEAD</literal></term>
      <listitem>
       <para>
        the query tree from the rule action with the rule
        qualification and the original query tree's qualification; and
        the original query tree with the negated rule qualification
        added
       </para>
      </listitem>
     </varlistentry>
    </variablelist>

    Finally, if the rule is <literal>ALSO</literal>, the unchanged original query tree is
    added to the list. Since only qualified <literal>INSTEAD</literal> rules already add the
    original query tree, we end up with either one or two output query trees
    for a rule with one action.
</para>

<para>
    For <literal>ON INSERT</literal> rules, the original query (if not suppressed by <literal>INSTEAD</literal>)
    is done before any actions added by rules.  This allows the actions to
    see the inserted row(s).  But for <literal>ON UPDATE</literal> and <literal>ON
    DELETE</literal> rules, the original query is done after