Re: sql_drop Event Trigger - Mailing list pgsql-hackers

From Tom Lane
Subject Re: sql_drop Event Trigger
Date
Msg-id 7091.1360168238@sss.pgh.pa.us
Whole thread Raw
In response to Re: sql_drop Event Trigger  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: sql_drop Event Trigger  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: sql_drop Event Trigger
Next
From: Phil Sorber
Date:
Subject: Re: get_progname() should not be const char *?