Re: transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

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