Re: sql_drop Event Trigger

On Wed, Feb 6, 2013 at 11:30 AM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> Dimitri Fontaine escribió:
>>> 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?
>>
>> 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?

Well, if it has a different firing point than ddl_command_end, then
there could well be some point to having it after all. But I'm far
from convinced that the proposed firing point can be made safe without
a major refactoring. I think this is the sort of things where "design
before code" ought to be the cardinal rule.

>> 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?

That particular problem does not bother me, personally. But the
possibility of ending up with corrupt system catalog contents does.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company