Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take)

On Wed, May 10, 2017 at 11:22 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Wed, May 10, 2017 at 9:57 AM, Alvaro Herrera
> <alvherre@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