On Tue, May 9, 2017 at 10:29 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> In master, the decision to populate transition tables happens in
> AfterTriggerSaveEvent (called by the ExecAR* functions) in trigger.c.
> It does that if it sees that there are triggers on the
> relation-being-modified that have transition tables.
>
> With this patch, nodeModifyTuple.c makes a 'TriggerTransitionFilter'
> object to override that behaviour, if there are child tables of either
> kind. That is passed to the ExecAR* functions and thence
> AfterTriggerSaveEvent, overriding its usual behaviour, so that it can
> know that it needs collect tuples from child nodes and how to convert
> them to the layout needed for the tuplestores if necessary.
>
> Thoughts? I'm not yet sure about the locking situation. Generally
> needs some more testing.
Here is a new version with tidied up tests and a couple of small bug
fixes. However, I've realised that there is a surprising behaviour
with this approach, and I'm not sure what to do about it.
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. Now our policy of firing the statement level triggers only for
the named relation but firing row-level triggers for all modified
relations leads to a tricky problem for the inheritance case: what
type of transition tuples should the child table's row-level triggers
see?
Suppose you have an inheritance hierarchy like this:
animal
-> mammal
-> cat
You define a statement-level trigger on "animal" and another
statement-level trigger on "mammal". You define a row-level trigger
on "cat". When you update either "animal" or "mammal", the row
triggers on "cat" might run. Row-level triggers on "cat" see OLD and
NEW as "cat" tuples, of course, but if they are configured to see
transition tables, should they see "cat", "mammal" or "animal" tuples
in the transition tables? With my patch as it is, that depends on
which level of the hierarchy you explicitly updated!
No such problem exists for partition hierarchies since the tables all
appear as the same type to user code (though conversions may be
happening for technical reasons).
--
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
