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.
This commit is contained in:
Tom Lane 2004-07-17 17:28:29 +00:00
parent 694b9ef783
commit 7f72fd8c47

View File

@ -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);