Re: sql_drop Event Trigger

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I might be forgetting something, but doesn't dependency.c work by first
>> constructing a list of all the objects it's going to drop, and only then
>> dropping them? Could we inject a "pre deletion" event trigger call at
>> the point where the list is completed?

> What happens if the event trigger itself deletes objects? From the list?

Throw an error. Per previous discussion, the trigger does not get to do
anything that would affect the results of "parse analysis" of the
command, and that list is exactly those results.

> Plus, as we seem to be chasing minimal set of
> features per patch, I would think that getting the list of Objects OIDs
> that are already dropped is a well enough defined set of minimal feature
> for this very patch, that we will be in a position to extend later given
> some time.

Well, a list of object OIDs is of exactly zero use once the command
has been carried out. So I don't think that that represents a useful
or even very testable feature on its own, if there's no provision to
fire user code while the OIDs are still in the catalogs.

regards, tom lane