Re: support for MERGE

On 2022-Aug-01, Álvaro Herrera wrote:

> > > If <command>MERGE</command> attempts an <command>INSERT</command>
> > > and a unique index is present and a duplicate row is concurrently
> > > + inserted, then a uniqueness violation error is raised;
> > > + <command>MERGE</command> does not attempt to avoid such
> > > + errors by evaluating <literal>MATCHED</literal> conditions.
> >
> > This was a portion of a chang that was committed as ffffeebf2.
> >
> > But I don't understand why this changed from "does not attempt to avoid the
> > error by executing an <command>UPDATE</command>." to "...by evaluating
> > <literal>MATCHED</literal> conditions."
> >
> > Maybe it means to say "..by re-starting evaluation of match conditions".
>
> Yeah, my thought there is that it may also be possible that the action
> that would run if the conditions are re-run is a DELETE or a WHEN
> MATCHED THEN DO NOTHING; so saying "by executing an UPDATE" it leaves
> out those possibilities. IOW if we're evaluating NOT MATCHED INSERT and
> we find a duplicate, we do not go back to MATCHED.

So I propose to leave it as

If <command>MERGE</command> attempts an <command>INSERT</command>
and a unique index is present and a duplicate row is concurrently
inserted, then a uniqueness violation error is raised;
<command>MERGE</command> does not attempt to avoid such
errors by restarting evaluation of <literal>MATCHED</literal>
conditions.

(Is "re-starting" better than "restarting"?)

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
Voy a acabar con todos los humanos / con los humanos yo acabaré
voy a acabar con todos (bis) / con todos los humanos acabaré ¡acabaré! (Bender)