On Wed, Jun 7, 2017 at 3:42 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Wed, Jun 7, 2017 at 7:27 PM, Thomas Munro > <thomas.mu...@enterprisedb.com> wrote: >> On Wed, Jun 7, 2017 at 10:47 AM, Peter Geoghegan <p...@bowt.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.
The idea of transition tables is that you see all changes to the target of a single statement in the form of delta relations -- with and "old" table for any rows affected by a delete or update and a "new" table for any rows affected by an update or delete. If we have a single statement that combines INSERT and UPDATE behaviors, it might make sense to have an "old" table for updates and a single "new" table for both. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
