On Wed, 11 Feb 2004, Tom Lane wrote: > Gavin Sherry <[EMAIL PROTECTED]> writes: > > There have been a few discussions about triggers on system tables in > > the past and the problems with such triggers seem to be: > > I think the killer problem is that we couldn't allow triggers on system > tables to do very much. By definition, the database is in an inconsistent > state if we are in the middle of updating system tables. We can't allow > arbitrary bits of SQL to run then. > > It might be feasible to allow AFTER triggers on system tables, since > those don't actually fire until end of statement, at which point things > are hopefully consistent again. I don't even want to think about > allowing BEFORE triggers.
Actually, all my tests (CREATE TABLE case) have been for AFTER triggers as I didn't want to look at BEFORE cases either. If the trigger is executed after all system catalog/index updates, plus CommandCounterIncrement(), we should be consistent, right? My idea is to provide a generic interface which is called inside ProcessUtility() after all other functions are called for the particular node we're handling. The nodetag itself will be passed to this generic function, the function will map nodetag to the relevant underlying system table, get the TriggerDesc for the relation and pass it and the relation data onto the trigger system. CREATE will call insert triggers, ALTER will call update triggers, DROP will call delete. If this sounds good, I think we can deal with AFTER ... STATEMENT level triggers without having to worry about constructing state. Thanks, Gavin ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
