Re: UPSERT wiki page, and SQL MERGE syntax - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: UPSERT wiki page, and SQL MERGE syntax
Date
Msg-id CAM3SWZQ_U+PMxqQ9HbirVYqj1KBiazgP1GbU5LfUR3CPCVXb6A@mail.gmail.com
Whole thread Raw
In response to Re: UPSERT wiki page, and SQL MERGE syntax  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-hackers
On Fri, Oct 10, 2014 at 11:55 AM, Kevin Grittner <kgrittn@ymail.com> wrote:
> I haven't read the patch, but the discussion has made that clear,
> yes.  Try to take agreement on a point gracefully, will ya?  ;-)

Heh, sorry. I did literally mean what I said - it wasn't 100% clear to
me that you got that. It's safest to not make any assumptions like
that.

>> AFAICT the only confusion that my patch has is with statement-level
>> triggers, as discussed on the Wiki page. I think that the row-level
>> trigger behavior is fine; a lot more thought has gone into it.
>
> IMV it is clear that since the standard says that update or insert
> operations which affect zero rows fire the corresponding trigger,
> the statement level triggers for both should fire for an UPSERT,
> even if the set of affected rows for one or the other (or both!) is
> zero.  If we ever get transition relations, it will be easy to
> check the count of affected rows or otherwise behave appropriately
> based on what was done.

I think that you're probably right about that. Note that UPDATE rules
will not be applied to the "UPDATE portion" of the statement. Not sure
what to do about that, but I'm pretty sure that it's inevitable,
because the UPDATE is effectively the same top-level statement for the
purposes of rules.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: UPSERT wiki page, and SQL MERGE syntax
Next
From: Peter Geoghegan
Date:
Subject: Re: UPSERT wiki page, and SQL MERGE syntax