On Wed, May 10, 2017 at 11:22 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Wed, May 10, 2017 at 9:57 AM, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: >> Thomas Munro wrote: >> >>> Recall that transition tables can be specified for statement-level >>> triggers AND row-level triggers. If you specify them for row-level >>> triggers, then they can see all rows changed so far each time they >>> fire. >> >> Uhmm ... why do we do this? It seems like a great way to cause much >> confusion. Shouldn't we see the transition table containing the whole >> set for statement-level triggers only, and give row-level triggers just >> the individual affected row each time? > > I assumed that had come from the standard. I don't have a published > standard, but I have just taken a quick look at one of the publicly > available drafts dated 2006. I think its model is that the transition > tables are always conceptually there, and NEW and OLD are just range > variables over those tables. That may explain why transition tables > are mentioned in the context of row-level triggers, and it may be that > the spec's authors never intended row-level triggers to be able to see > the (partial) transition table other than through the range variables > that access exactly one row, but I don't see any wording that > explicitly says so in the spec. Do you? Thoughts, Kevin?
Hmm. DB2 has transition tables (invented them maybe?) and it allows OLD/NEW TABLE on row-level triggers: https://www.ibm.com/support/knowledgecenter/en/SSEPGG_10.1.0/com.ibm.db2.luw.admin.dbobj.doc/doc/t0020236.html -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
