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 a5a7deadcfd5933b33cfca936efe4d3db0837916..d5cdb909c33ea41664863b07356a96f52e2ee9e7 100644 (file)
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *       $PostgreSQL: pgsql/src/backend/commands/tablecmds.c,v 1.119 2004/07/11 23:13:53 tgl Exp $
+ *       $PostgreSQL: pgsql/src/backend/commands/tablecmds.c,v 1.120 2004/07/17 17:28:29 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -1706,6 +1706,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)
+                       CacheInvalidateRelcacheByRelid(pg_trigger->tgrelid);
+
                /* free up our scratch memory */
                pfree(newtgargs);
                heap_freetuple(tuple);