On Wed, May 10, 2017 at 8: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. Perhaps you could modify NamedTuplestorescan > to convert on the fly to the TupleDesc of the table that the row-level > trigger is attached to, using NULL for missing columns, but that'd be > a slightly strange too, depending on how you did it.
I don't think it's crazy from a user perspective, but the plan caching thing sounds like a problem. > Perhaps we should reject row-level triggers with transition tables on > tables that are part of an inheritance hierarchy, but allow them for > partitions. Sounds like a sensible solution. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
