Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > Dimitri Fontaine escribió: >> Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
