This is a stupid garden variety bug and I'm not sure why I didn't catch

it previously.  The patch included is against fairly current sources, but
it may apply cleanly against 7.0.2 as well.

On Fri, 6 Oct 2000, Vilson farias wrote:

> I found a irregular behavior with constraints.
>
> I can only set a referencial integrity between these tables when there are
> no data, even if there are no change to referential integrity violation.

diff --git a/src/backend/commands/command.c b/src/backend/commands/command.c
index 36f77f1bd6c4d1e1c93334e0136b82cb6734d8c9..a9b16c009e459439b190f51d8c2014c4799a841a 100644 (file)
--- a/src/backend/commands/command.c
+++ b/src/backend/commands/command.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *   $Header: /cvsroot/pgsql/src/backend/commands/Attic/command.c,v 1.105 2000/10/05 19:48:22 momjian Exp $
+ *   $Header: /cvsroot/pgsql/src/backend/commands/Attic/command.c,v 1.106 2000/10/10 17:13:30 momjian Exp $
  *
  * NOTES
  *   The PerformAddAttribute() code, like most of the relation
@@ -1389,15 +1389,18 @@ AlterTableAddConstraint(char *relationName,
                {
                    Ident      *fk_at = lfirst(list);
 
-                   trig.tgargs[count++] = fk_at->name;
+                   trig.tgargs[count] = fk_at->name;
+                   count+=2;
                }
+           count = 5;
            foreach(list, fkconstraint->pk_attrs)
                {
                    Ident      *pk_at = lfirst(list);
 
-                   trig.tgargs[count++] = pk_at->name;
+                   trig.tgargs[count] = pk_at->name;
+                   count+=2;
                }
-           trig.tgnargs = count;
+           trig.tgnargs = count-1;
 
            scan = heap_beginscan(rel, false, SnapshotNow, 0, NULL);
            AssertState(scan != NULL);