Horton

Re: [HACKERS] MERGE SQL Statement for PG11

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Pavan Deolasee <pavan.deolasee@2ndquadrant.com>, Stephen Frost <sfrost@snowman.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-02-06T03:49:29Z
Lists: pgsql-hackers 
On Sun, Feb 4, 2018 at 3:41 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> It is not clear to me what is exactly your concern if we try to follow
>> #2?  To me, #2 seems like a natural choice.
>
> At first, but it gives an anomaly so is not a good choice. The patch
> does behavior #5, it rechecks the conditions with the latest row.
>
> Otherwise
> WHEN MATCHED AND a=0 THEN UPDATE SET b=0
> WHEN MATCHED AND a=1 THEN UPDATE SET b=1
> would result in (a=1, b=0) in case of concurrent updates, which the
> user clearly doesn't want.

I am unable to understand this.  What are you presuming the tuple was
originally?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Add support for MERGE SQL command

  2. Add API of sorts for transition table handling in trigger.c

  3. Revert MERGE patch

  4. Fix several bugs related to ON CONFLICT's EXCLUDED pseudo relation.