We already have system triggers -- the FK triggers. I don't think we've had all that much trouble with them.
In the case of the FK triggers, it's intentional (and maybe even documented) that users should be able to place their own triggers before or after the FK triggers.
If it's documented I think it's well hidden ;-) ISTM that the fact that we implement FK constraints via triggers is really an implementation detail, not something the user should be encouraged to mess with.
Is there a good reason why partitioning triggers should be different?
Probably not. ISTM that the scheme should turn tgisconstraint into a multi-valued item (tgkind: 'u' = userland, 'c'= constraint, 'p' = partition or some such).
+1.
This seems to be the best way forward if we stick to triggers for partitioning. I think they appear to serve the purpose well for this use-case and maybe with this scheme they will be low-level enough too.
