MIME-Version: 1.0
In-Reply-To: 
 <CAH2-WzkNU1mUoop+8HApEezgucu-vZxijupLbwj4tSvvrOCPLw@mail.gmail.com>
References: 
 <CANP8+jKitBSrB7oTgT9CY2i1ObfOt36z0XMraQc+Xrz8QB0nXA@mail.gmail.com>
 <20171027124555.txawx6p6veikx25x@alvherre.pgsql>
 <CANP8+jKOQmnxo89bybX=+Fx3JuHDOwJ2aiihCHiWg3PMfcLkPA@mail.gmail.com>
 <CANP8+jLdJoqjzkEdfqy_Rw43gUk08btunpJVV7Yiw=UqtOtePw@mail.gmail.com>
 <CANP8+jJgS_KoN6DDteb_9-fUzfnp7Ytm9O5VE83dGpWp1pszkg@mail.gmail.com>
 <CAH2-WznpEqdzL_sgWOHfmb9jz6612JLkhdN5YcdmdW3qX3g4Uw@mail.gmail.com>
 <CANP8+jKTuZ5NDCLkqXBm9kMeaT-jNxxhkMg+FOpLni=pwOQ=BA@mail.gmail.com>
 <CANP8+jKJee2Luip7tv4KrK8R_EP5PbOvDD+vfUpp9uBFmfK9yg@mail.gmail.com>
 <CANP8+jK8YRSCrg8m8XiRMmoy9DfvL=hUQ1SpS=+y=920evbTvg@mail.gmail.com>
 <CAH2-WznPcu-7gDhWB-AG9BMamZ0sVKrwrHyoy=GLYy4-z01Emg@mail.gmail.com>
 <CANP8+j+UWRS-rm0QqFyFZmK3Xd2=EsXsXYO6BgAgxNZry4Hc6w@mail.gmail.com>
 <CAH2-WzkAjSN1H-ym-sSDh+6EJWmEhyHdDStzXDB+Fxt1hcKEgg@mail.gmail.com>
 <CANP8+j+rO5jnDATve3gokRf6Jhfss5DquFxgz74rhJero8sAGQ@mail.gmail.com>
 <CA+TgmoavFdPbCeB+QUSdeQieW2rhCdR54qndO_8irHOXrCjxUg@mail.gmail.com>
 <CAH2-Wz=prLgvc0He8PYDE6px-S+k4yoXAHpV7P+RpwrO=f=BAA@mail.gmail.com>
 <CA+TgmoZDL-caukHkWet7sr7sqr0-e2T91+DEvhqeN5sfqsMjqw@mail.gmail.com>
 <CAH2-WzkNU1mUoop+8HApEezgucu-vZxijupLbwj4tSvvrOCPLw@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Sun, 4 Feb 2018 12:02:09 +0530
Message-ID: 
 <CAA4eK1JwoUX4BNsAbW9mGrRsZdc0Co2a44zd0UQftF58iiLAjg@mail.gmail.com>
Subject: Re: [HACKERS] MERGE SQL Statement for PG11
To: Peter Geoghegan <pg@bowt.ie>
Cc: Robert Haas <robertmhaas@gmail.com>, Simon Riggs <simon@2ndquadrant.com>,
	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>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Jan 31, 2018 at 11:37 PM, Peter Geoghegan <pg@bowt.ie> wrote:
> On Wed, Jan 31, 2018 at 7:17 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I don't fully grok merge but suppose you have:
>>
>> WHEN MATCHED AND a = 0 THEN UPDATE ...
>> WHEN MATCHED AND a = 1 THEN UPDATE ...
>> WHEN NOT MATCHED THEN INSERT ...
>>
>> Suppose you match a tuple with a = 0 but, upon trying to update it,
>> find that it's been updated to a = 1.  It seems like there are a few
>> possible behaviors:
>>
>> 1. Throw an error!  I guess this is what the patch does now.
>
> Right.
>
>> 2. Do absolutely nothing.  I think this is what would happen with an
>> ordinary UPDATE; the tuple fails the EPQ recheck and so is not
>> updated, but that doesn't trigger anything else.
>
> I think #2 is fine if you're talking about join quals. Which, of
> course, you're not. These WHEN quals really do feel like
> tuple-at-a-time procedural code, more than set-orientated quals (if
> that wasn't true, we'd have to allow cardinality violations, which we
> at least try to avoid). Simon said something like "the SQL standard
> requires that WHEN quals be evaluated first" at one point, which makes
> sense to me.
>

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.


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com