On Wed, 11 Feb 2004, Tom Lane wrote:
> 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.
Okay then.
>
> 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
Yeah. That's what I liked about restricting it to CREATE TABLE, etc. We
know when the state is consistent.
> 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?
Do you have an example at hand of a system function which will face this
problem so that I can see what is involved?
Thanks,
Gavin
