Re: sql_drop Event Trigger - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: sql_drop Event Trigger
Date
Msg-id m28v71jtgo.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: sql_drop Event Trigger  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: sql_drop Event Trigger  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Dimitri Fontaine escribió:
>> 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?
>
> Yes, this is what I'm proposing.

So, I add back the "sql_drop" event and implement it in dependency.c,
and keep the list for later processing from "ddl_command_end", right?

Robert, you specifically opposed to "sql_drop" and I just removed it
from the patch. What do you think now? Also, should that be a follow-up
patch to the current one for your reviewing purposes?

>> What happens if the event trigger itself deletes objects? From the list?
>
> I replied to this above: raise an error.  (How to do that is an open
> implementation question, but I proposed a simple idea upthread).

Well, can the list of objects that get dropped for CASCADE change in
between releases? If it ever does, that means that your event trigger
that used to work before is not broken after upgrade. Is that ok?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system
Next
From: Tom Lane
Date:
Subject: Re: sql_drop Event Trigger