from the target table to be returned.  An unqualified column
      name from the target table, or a column name or <literal>*</literal>
      qualified using the target table name or alias will return new values
      for <literal>INSERT</literal> and <literal>UPDATE</literal> actions, and
      old values for <literal>DELETE</literal> actions.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">output_name</replaceable></term>
    <listitem>
     <para>
      A name to use for a returned column.
     </para>
    </listitem>
   </varlistentry>

  </variablelist>
 </refsect1>

 <refsect1>
  <title>Outputs</title>

  <para>
   On successful completion, a <command>MERGE</command> command returns a command
   tag of the form
<screen>
MERGE <replaceable class="parameter">total_count</replaceable>
</screen>
   The <replaceable class="parameter">total_count</replaceable> is the total
   number of rows changed (whether inserted, updated, or deleted).
   If <replaceable class="parameter">total_count</replaceable> is 0, no rows
   were changed in any way.
  </para>

  <para>
   If the <command>MERGE</command> command contains a <literal>RETURNING</literal>
   clause, the result will be similar to that of a <command>SELECT</command>
   statement containing the columns and values defined in the
   <literal>RETURNING</literal> list, computed over the row(s) inserted, updated,
   or deleted by the command.
  </para>
 </refsect1>

 <refsect1>
  <title>Notes</title>

  <para>
   The following steps take place during the execution of
   <command>MERGE</command>.
    <orderedlist>
     <listitem>
      <para>
       Perform any <literal>BEFORE STATEMENT</literal> triggers for all
       actions specified, whether or not their <literal>WHEN</literal>
       clauses match.
      </para>
     </listitem>
     <listitem>
      <para>
       Perform a join from source to target table.
       The resulting query will be optimized normally and will produce
       a set of candidate change rows. For each candidate change row,
       <orderedlist>
        <listitem>
         <para>
          Evaluate whether each row is <literal>MATCHED</literal>,
          <literal>NOT MATCHED BY SOURCE</literal>, or
          <literal>NOT MATCHED [BY TARGET]</literal>.
         </para>
        </listitem>
        <listitem>
         <para>
          Test each <literal>WHEN</literal> condition in the order
          specified until one returns true.
         </para>
        </listitem>
        <listitem>
         <para>
          When a condition returns true, perform the following actions:
          <orderedlist>
           <listitem>
            <para>
             Perform any <literal>BEFORE ROW</literal> triggers that fire
             for the action's event type.
            </para>
           </listitem>
           <listitem>
            <para>
             Perform the specified action, invoking any check constraints on the
             target table.
            </para>
           </listitem>
           <listitem>
            <para>
             Perform any <literal>AFTER ROW</literal> triggers that fire for
             the action's event type.
            </para>
           </listitem>
          </orderedlist>
          If the target relation is a view with <literal>INSTEAD OF ROW</literal>
          triggers for the action's event type, they are used to perform the
          action instead.
         </para>
        </listitem>
       </orderedlist></para>
     </listitem>
     <listitem>
      <para>
       Perform any <literal>AFTER STATEMENT</literal> triggers for actions
       specified, whether or not they actually occur.  This is similar to the
       behavior of an <command>UPDATE</command> statement that modifies no rows.
      </para>
     </listitem>
    </orderedlist>
   In summary, statement triggers for an event type (say,
   <command>INSERT</command>) will be fired whenever we
   <emphasis>specify</emphasis>