Re: sql_drop Event Trigger

On Thu, Feb 21, 2013 at 12:52 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
>> What if the object that gets whacked around is one of the named
>> objects rather than some dependency thereof? Suppose for example that
>> the event trigger drops the same object that the user tried to drop.
>> We need to error out cleanly in that case, not blindly proceed with
>> the drop.
>
> An error is raised, which I think is sane. I think this peculiar
> situation warrants its own few lines in the new regression test.

Definitely.

> One funny thing I noticed is that if I add a column in a table being
> dropped, the targetObjects list does not change after the trigger has
> run. The reason for this is that the table's attributes are not present
> in the targetObjects list; instead they are dropped manually by calling
> DeleteAttributeTuples(). I saw that you can end up with lingering
> pg_attribute entries that way.

I venture to guess that this is exactly the sort of thing that made
Tom argue upthread that we shouldn't be putting a firing point in the
middle of the drop operation. Any slip-ups here will result in
corrupt catalogs, and it's not exactly future-proof either.

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