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