There is no need to define tuple routing triggers. CopyFrom() and ExecInsert() determine target partition just before performing heap_insert() and ExecInsertIndexTuples(). IOW, any BR triggers and constraints (on parent) are executed for tuple before being routed to a partition. If no partition can be found, it's an error.
Because row-level AFTER triggers need to save ItemPointers in trigger event data and defining triggers on partitions (which is where tuples really go) is not allowed, I could not find a straightforward way to implement them. So, perhaps we should allow (only) row-level AFTER triggers on partitions or think of modifying trigger.c to know about this twist explicitly.
I think tables will eventually need FK support; its not sustainable as a long term restriction, though perhaps its something we can do in a later patch.
You haven't specified what would happen if an UPDATE would change a row's partition. I'm happy to add this to the list of restrictions by saying that the partition key cannot be updated.
We'll need regression tests that cover each restriction and docs that match. This is not something we should leave until last. People read the docs to understand the feature, helping them to reach consensus. So it is for you to provide the docs before, not wait until later. I will begin a code review once you tell me docs and tests are present. We all want the feature, so its all about the details now.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services