Date: Wed, 27 Sep 2023 19:42:42 -0400
From: Bruce Momjian <bruce@momjian.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: dwayne.towell@gmail.com, pgsql-docs@lists.postgresql.org
Subject: Re: MERGE examples not clear
Message-ID: <ZRS98kJEt9AZAtpM@momjian.us>
References: <167699245721.1902146.6479762301617101634@wrigleys.postgresql.org>
 <CAKFQuwZrP1_hRLT8JXdfX4Bi20-Y3oGPsaKeRVe9bNzngFP+JQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="xHvpDtqq0WSJtx0g"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAKFQuwZrP1_hRLT8JXdfX4Bi20-Y3oGPsaKeRVe9bNzngFP+JQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ZRS98kJEt9AZAtpM%40momjian.us>
Precedence: bulk


--xHvpDtqq0WSJtx0g
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

On Tue, Feb 21, 2023 at 08:56:50AM -0700, David G. Johnston wrote:
> On Tue, Feb 21, 2023 at 8:35 AM PG Doc comments form <noreply@postgresql.org>
> wrote:
> 
>     The following documentation comment has been logged on the website:
> 
>     Page: https://www.postgresql.org/docs/15/sql-merge.html
>     Description:
> 
>     On this page: https://www.postgresql.org/docs/15/sql-merge.html
>     the first and second examples seems to be contrasted (by "this would be
>     exactly equivalent to the following statement"), however the difference
>     does
>     not seem to related to the stated reason ("the MATCHED result does not
>     change"). It seems like the difference should involve the order of WHEN
>     clauses?
>     Of course, it might be that I don't understand the point, in which case
>     maybe the point could be stated more clearly?
> 
> 
> Yeah, that is a pretty poor pair of examples.  Given that a given customer can
> reasonably be assumed to have more than one recent transaction the MERGE has a
> good chance of failing.
> 
> The only difference between the two is the second one uses an explicit subquery
> as the source while the first simply names a table.  If the subquery had a
> GROUP BY customer_id that would be a good change explaining that the second
> query is different because it is resilient in the face of duplicate customer
> recent transactions.
> 
> While here...source_alias (...completely hides...the fact that a query was
> issued).  What?  Probably it should read (not verified) that it is actually
> required when the source is a query (maybe tweaking the syntax to match).

The attached patch removes the second example, which doesn't seem to add
much.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

--xHvpDtqq0WSJtx0g
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="merge.diff"

diff --git a/doc/src/sgml/ref/merge.sgml b/doc/src/sgml/ref/merge.sgml
index 0995fe0c04..4544ce92b3 100644
--- a/doc/src/sgml/ref/merge.sgml
+++ b/doc/src/sgml/ref/merge.sgml
@@ -582,23 +582,6 @@ WHEN NOT MATCHED THEN
 </programlisting>
   </para>
 
-  <para>
-   Notice that this would be exactly equivalent to the following
-   statement because the <literal>MATCHED</literal> result does not change
-   during execution.
-
-<programlisting>
-MERGE INTO customer_account ca
-USING (SELECT customer_id, transaction_value FROM recent_transactions) AS t
-ON t.customer_id = ca.customer_id
-WHEN MATCHED THEN
-  UPDATE SET balance = balance + transaction_value
-WHEN NOT MATCHED THEN
-  INSERT (customer_id, balance)
-  VALUES (t.customer_id, t.transaction_value);
-</programlisting>
-  </para>
-
   <para>
    Attempt to insert a new stock item along with the quantity of stock. If
    the item already exists, instead update the stock count of the existing

--xHvpDtqq0WSJtx0g--