Re: FOR EACH ROW triggers on partitioned tables

Here's v8, which addresses all your comments except the doc updates. I
added a few more tests, too. Thanks for the review! I intend to commit
this shortly, probably not before Friday to give some more time for
others to review/comment.

Some notes:

Peter Eisentraut wrote:

> I'm not sure why you have the CommandCounterIncrement() changes in
> separate patches.

Clearly it was wise to have it separately, because it was not entirely
trivial to fix the unexpected fallout :-)

> I'm wondering about deferrable unique constraint triggers. In index.c,
> the CreateTrigger() call doesn't pass any parent trigger OID. How is
> this meant to work? I mean, it does work, it seems. Some comments maybe.

Yeah, it seems pretty complicated ... it already worked this way: if you
don't pass a constraint OID, the constraint is created internally. We
make use of that here.

> What is the story with transition tables? Why are they not supported?
> I don't understand this comment in CreateTrigger():
>
> + /*
> + * Disallow use of transition tables. If this partitioned table
> + * has any partitions, the error would occur below; but if it
> + * doesn't then we would only hit that code when the first CREATE
> + * TABLE ... PARTITION OF is executed, which is too late. Check
> + * early to avoid the problem.
> + */
>
> Earlier in the thread, others have indicated that transition tables
> should work.

Yeah, this is a pre-existing restriction actually -- it was purposefully
introduced by commit 501ed02cf6f4. Maybe it can be lifted, but I don't
think it's this patch's job to do so. I reworded this comment.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services