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

On Wed, May 17, 2017 at 10:13 AM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:
> On Tue, May 16, 2017 at 4:50 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>>
>> 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...
>
> I agree that we can safely go that far, but not farther. Thanks!

Here is that patch. Thoughts?

On Wed, May 10, 2017 at 3:41 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Hmm. What if the partitioning hierarchy contains foreign tables?

No tuples are collected from partitions that are foreign tables. See
the attached demonstration. I wasn't sure whether and if so where to
include that in the regression tests because it needs a contrib
module.

Robert and I discussed this off-list and came up with some options:
(1) document that as the current behaviour (where?), (2) figure out
how to prevent that situation from arising, (3) raise some kind of
runtime error if foreign transition tuples need to be collected.

Option 2 would seem to require us to lock the whole chain of ancestors
to check for statement-level triggers with transition tables, which
seems unpleasant, and option 3 is conceptually similar to the
execution time insertion failure. It's debatable wither 3 or 1 is
more surprising or inconvenient to users. I vote for option 1 as a
stop-gap measure (and I hope that someone will soon fix transition
tuple capture for foreign tables generally). However, it's a bit
inconsistent that we explicitly reject triggers with transition tables
on foreign tables directly, but let them silently fail to capture
anything when they're indirectly accessed via a parent relation.
Thoughts?

--
Thomas Munro
http://www.enterprisedb.com