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.

diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index b77faed0d3e841303dc4e6d618053d954b2e97a4..2c3a3760f2f0b842e7b783d268c33a644699ba83 100644 (file)
--- a/src/backend/commands/tablecmds.c
+++ b/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);