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:


Thomas Munro

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to