From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PG10 transition tables, wCTEs and multiple operations on the same table |
Date: | 2017-06-07 08:42:52 |
Message-ID: | CAEepm=2ULhMCENhHtkDxoTi6BKDju3KXHVVMk41g3zQFjkPf=g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 7, 2017 at 7:27 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Wed, Jun 7, 2017 at 10:47 AM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>> I suppose you'll need two tuplestores for the ON CONFLICT DO UPDATE
>> case -- one for updated tuples, and the other for inserted tuples.
>
> Hmm. Right. INSERT ... ON CONFLICT DO UPDATE causes both AFTER
> INSERT and AFTER UPDATE statement-level triggers to be fired, but then
> both kinds see all the tuples -- those that were inserted and those
> that were updated. That's not right.
Or maybe it is right. We're out of spec here, so we'd basically have
to decide (though MERGE's behaviour would be interesting to compare
with). What we have seems reasonable for an AFTER INSERT OR UPDATE
statement-level trigger, I think. It's just a bit questionable if you
asked for just one of those things. The question is whether the
trigger's 'when' clause is supposed to refer to the type of statement
you ran or the way individual rows turned out to be processed in our
out-of-standard ON CONFLICT case. If you take the former view then we
could simply decree that such a statement is both an INSERT and an
UPDATE for trigger selection purposes.
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2017-06-07 09:46:03 | Re: UPDATE of partition key |
Previous Message | Alexander Korotkov | 2017-06-07 08:33:38 | Re: Challenges preventing us moving to 64 bit transaction id (XID)? |