Change FK trigger naming convention to fix self-referential FKs.

Use names like "RI_ConstraintTrigger_a_NNNN" for FK action triggers and
"RI_ConstraintTrigger_c_NNNN" for FK check triggers.  This ensures the
action trigger fires first in self-referential cases where the very same
row update fires both an action and a check trigger.  This change provides
a non-probabilistic solution for bug #6268, at the risk that it could break
client code that is making assumptions about the exact names assigned to
auto-generated FK triggers.  Hence, change this in HEAD only.  No need for
forced initdb since old triggers continue to work fine.

diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index f82157b62c6b25203dbcfbb8ea4f0cfdbe7e7dc7..c4622c04125bbca7d3fa75e538c5737e4aa4fb96 100644 (file)
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -6467,8 +6467,17 @@ CreateFKCheckTrigger(RangeVar *myRel, Constraint *fkconstraint,
 {
        CreateTrigStmt *fk_trigger;
 
+       /*
+        * Note: for a self-referential FK (referencing and referenced tables are
+        * the same), it is important that the ON UPDATE action fires before the
+        * CHECK action, since both triggers will fire on the same row during an
+        * UPDATE event; otherwise the CHECK trigger will be checking a non-final
+        * state of the row.  Triggers fire in name order, so we ensure this by
+        * using names like "RI_ConstraintTrigger_a_NNNN" for the action triggers
+        * and "RI_ConstraintTrigger_c_NNNN" for the check triggers.
+        */
        fk_trigger = makeNode(CreateTrigStmt);
-       fk_trigger->trigname = "RI_ConstraintTrigger";
+       fk_trigger->trigname = "RI_ConstraintTrigger_c";
        fk_trigger->relation = myRel;
        fk_trigger->row = true;
        fk_trigger->timing = TRIGGER_TYPE_AFTER;
@@ -6524,7 +6533,7 @@ createForeignKeyTriggers(Relation rel, Constraint *fkconstraint,
         * DELETE action on the referenced table.
         */
        fk_trigger = makeNode(CreateTrigStmt);
-       fk_trigger->trigname = "RI_ConstraintTrigger";
+       fk_trigger->trigname = "RI_ConstraintTrigger_a";
        fk_trigger->relation = fkconstraint->pktable;
        fk_trigger->row = true;
        fk_trigger->timing = TRIGGER_TYPE_AFTER;
@@ -6577,7 +6586,7 @@ createForeignKeyTriggers(Relation rel, Constraint *fkconstraint,
         * UPDATE action on the referenced table.
         */
        fk_trigger = makeNode(CreateTrigStmt);
-       fk_trigger->trigname = "RI_ConstraintTrigger";
+       fk_trigger->trigname = "RI_ConstraintTrigger_a";
        fk_trigger->relation = fkconstraint->pktable;
        fk_trigger->row = true;
        fk_trigger->timing = TRIGGER_TYPE_AFTER;
@@ -6628,17 +6637,6 @@ createForeignKeyTriggers(Relation rel, Constraint *fkconstraint,
        /*
         * Build and execute CREATE CONSTRAINT TRIGGER statements for the CHECK
         * action for both INSERTs and UPDATEs on the referencing table.
-        *
-        * Note: for a self-referential FK (referencing and referenced tables are
-        * the same), it is important that the ON UPDATE action fires before the
-        * CHECK action, since both triggers will fire on the same row during an
-        * UPDATE event; otherwise the CHECK trigger will be checking a non-final
-        * state of the row.  Because triggers fire in name order, we are
-        * effectively relying on the OIDs of the triggers to sort correctly as
-        * text.  This will work except when the OID counter wraps around or adds
-        * a digit, eg "99999" sorts after "100000".  That is infrequent enough,
-        * and the use of self-referential FKs is rare enough, that we live with
-        * it for now.  There will be a real fix in PG 9.2.
         */
        CreateFKCheckTrigger(myRel, fkconstraint, constraintOid, indexOid, true);
        CreateFKCheckTrigger(myRel, fkconstraint, constraintOid, indexOid, false);