Home Explore Blog CI



postgresql

9th chunk of `doc/src/sgml/ref/merge.sgml`
b8defbd42286d0b789f5fb79683bf107bdb6ad52895485260000000100000fb2
 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>

Title: MERGE Statement Outputs and Execution Notes
Summary
This section describes the outputs and execution steps of the MERGE command. It details the command tag returned upon completion, which indicates the total number of rows changed. It also explains how the RETURNING clause functions similarly to a SELECT statement. The section further outlines the sequence of operations during MERGE execution, including BEFORE STATEMENT, and AFTER STATEMENT triggers, join operations between source and target tables, condition evaluation, and action execution based on matching conditions.