When renaming a column that participates in a foreign key, we must

force relcache rebuild for the other table as well as the column's
own table.  Otherwise, already-cached foreign key triggers will stop
working.  Per example from Alexander Pravking.

src/backend/commands/tablecmds.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/backend/commands/tablecmds.c,v 1.91 2003/10/13 22:47:15 momjian Exp $
+ *	  $Header: /cvsroot/pgsql/src/backend/commands/tablecmds.c,v 1.91.2.1 2004/07/17 17:28:47 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -1534,6 +1534,20 @@ update_ri_trigger_args(Oid relid,
 
 		CatalogUpdateIndexes(tgrel, tuple);
 
+		/*
+		 * Invalidate trigger's relation's relcache entry so that other
+		 * backends (and this one too!) are sent SI message to make them
+		 * rebuild relcache entries.  (Ideally this should happen
+		 * automatically...)
+		 *
+		 * We can skip this for triggers on relid itself, since that
+		 * relcache flush will happen anyway due to the table or column
+		 * rename.  We just need to catch the far ends of RI relationships.
+		 */
+		pg_trigger = (Form_pg_trigger) GETSTRUCT(tuple);
+		if (pg_trigger->tgrelid != relid)
+			CacheInvalidateRelcache(pg_trigger->tgrelid);
+
 		/* free up our scratch memory */
 		pfree(newtgargs);
 		heap_freetuple(tuple);