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

On Wed, May 10, 2017 at 8:02 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Wed, May 10, 2017 at 11:10 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)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