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

On Tue, May 2, 2017 at 9:44 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> I think that we should only capture transition tuples captured from
> the explicitly named relation, since we only fire AFTER STATEMENT
> triggers on that relation. I see no inconsistency with the policy of
> rejecting transition tables on partitioned tables (as I proposed and
> Kevin accepted[1]), because partitioned tables can't have any data so
> there would be no point. In contrast, every parent table in an
> inheritance hierarchy is also a regular table and can hold data, so I
> think we should allow transition tables on them, and capture
> transition tuples from that table only when you modify it directly.

I suspect that most users would find it more useful to capture all of
the rows that the statement actually touched, regardless of whether
they hit the named table or an inheritance child. I just don't know
if it's practical to make that work. (And, of course, I don't know if
other people agree with my assessment of what is useful ... but
generally there seems to be support for making partitioned tables, at
least, look more like a single table that happens to have partitions
and less like a bunch of separate tables attached to each other with
duct tape.)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company