Gavin Sherry <swm@linuxworld.com.au> writes:
> 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.
I didn't actually much care for the "abstract event" aspect of your
proposal. I think that that presupposes too much about what people
will want to do with such triggers. Plus you still have to define
what data will be supplied to the trigger. I think it's fine to make
these things be real triggers that get real row values. We just have
to pay attention to calling them at a safe time.
One "state problem" that needs to be thought about is that many of the
system functions are implemented in a way that involves multiple steps
of updates on a single row. (In contrast, an ordinary UPDATE command
can't change a row more than once.) The intermediate states of these
rows are probably good examples of the sort of inconsistent data we
don't want to expose --- not only because they are inconsistent, but
because the exact intermediate states are implementation details that
are highly likely to change across versions. Can we collapse such
events together so that the user triggers see only the initial and final
states, and not the intermediate states?
regards, tom lane
