On Wed, May 17, 2017 at 9:20 AM, Kevin Grittner <kgri...@gmail.com> wrote: > On Wed, May 10, 2017 at 7:02 AM, Thomas Munro > <thomas.mu...@enterprisedb.com> wrote: >> On Wed, May 10, 2017 at 11:10 PM, Thomas Munro >> <thomas.mu...@enterprisedb.com> wrote: >>> 2. If you attach a row-level trigger with transition tables to any >>> inheritance child, it will see transition tuples from all tables in >>> the inheritance hierarchy at or below the directly named table that >>> were modified by the same statement, sliced so that they appear as >>> tuples from the directly named table. >> >> Of course that's a bit crazy, not only for trigger authors to >> understand and deal with, but also for plan caching: it just doesn't >> really make sense to have a database object, even an ephemeral one, >> whose type changes depending on how the trigger was invoked, because >> the plans stick around. > > The patch to add transition tables changed caching of a trigger > function to key on the combination of the function and the target > relation, rather than having one cache entry regardless of the > target table.
Right. That works as long as triggers always see tuples in the format of the relation that they're attached to, and I think that's the only sensible choice. The problem I was thinking about was this: We have only one pair of tuplestores and in the current design it holds tuples of a uniform format, yet it may (eventually) need to be scanned by a statement trigger attached to a the named relation AND any number of row triggers attached to children with potentially different formats. That implies some extra conversions are required at scan time. I had a more ambitious patch that would deal with sone of that by tracking storage format and scan format separately (next time your row trigger is invoked the scan format will be the same but the storage format may be different depending on which relation you named in a query), but I'm putting that to one side for this release. That was a bit of a rabbit hole, and there are some tricky design questions about tuple conversions (to behave like DB2 with subtables may even require tuplestore with per-tuple type information) and also the subset of rows that each row trigger should see (which may require extra tuple origin metadata or separate tuplestores). I'm about to post a much simpler patch that collects uniform tuples from children, addressing the reported bug, and simply rejects transition tables on row-triggers on tables that are in either kind of inheritance hierarchy. More soon... -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers