On Wed, Jun 7, 2017 at 2:19 PM, Kevin Grittner <kgri...@gmail.com> wrote: > 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.
My assumption would be that since you have as many as two statement-level triggers firing that could reference transition tables when ON CONFLICT DO UPDATE is used (one AFTER UPDATE statement level trigger, and another AFTER INSERT statement level trigger), there'd be separation at that level. You'd see updated tuples with one, and inserted within the other. While INSERT ON CONFLICT DO UPDATE is essentially one statement, it behaves as two statements in certain limited ways. IIRC MERGE as implemented in other systems has severe restrictions on things like row level triggers work (i.e. they simply don't work), and so they don't provide much in the way of guidance. My assumption about how transition tables ought to behave here is based on the simple fact that we already fire both AFTER statement-level triggers, plus my sense of aesthetics, or bias. I admit that I might be missing the point, but if I am it would be useful to know how. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
