On 06 Nov 2001 at 14:54 (-0500), Tom Lane wrote:
| Brent Verner <brent@rcfile.org> writes:
| > I've almost got the ALTER TABLE RENAME fixed so it doesn't break
| > triggers referring to the renamed column. The final problem is that
| > after the pg_trigger.tgargs is updated, that change is not visible
| > in the current backend.
|
| This should happen automatically as a consequence of the relcache flush
| message. Doing a manual RelationClearRelation or whatever is NOT the
| answer; if you find yourself doing that, it means that other backends
| aren't hearing about the change either.
gotcha. I don't know what you mean by 'relcache flush message,' but
I'll figure that out soon ;-)
| The usual way to force a relcache flush is to update the relation's
| pg_class row. Now that I think about it, I'm not sure ALTER TABLE
| RENAME COLUMN would have any direct reason to do that, so it may be
| broken already in this regard. Does the relcache entry's column
| data get updated with the new name?
The relation->triggerdesc still has the old tgargs after updating the
pg_trigger table, so the triggered RI_ function is called with the
old arguments.
It is probably noteworthy that I am directly modifying the tgargs
in the pg_trigger table, via simple_heap_update(). This modfication
is made at the end of renameatt() in rename.c. Could making this
change prior to the column rename cause the 'relcache flush message'
to do the right thing? [I'm going to try this as soon as I'm off work.]
Also, is directly updating the pg_trigger table advisable? I'll
look further at trigger.c to see if I overlooked any utility to do
this cleaner.
cheers. brent
--
"Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing." -- Duane Allman