Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take) - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take)
Date
Msg-id CACjxUsNciYMa9ZzV8HadONwhtZx1AqJkcZ-DEGJRh+xRSAi3Qw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take)  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take)
List pgsql-hackers
On Wed, May 10, 2017 at 7:02 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Wed, May 10, 2017 at 11:10 PM, Thomas Munro <thomas.munro@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.

--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: [HACKERS] Hash Functions
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take)