On Wed, 11 Feb 2004, Tom Lane wrote:
> Gavin Sherry <swm@linuxworld.com.au> 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