Re: sql_drop Event Trigger - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: sql_drop Event Trigger
Date
Msg-id m2bob4xhqi.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: sql_drop Event Trigger  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: sql_drop Event Trigger  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: sql_drop Event Trigger  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> I think it's fairly obvious that
> (1) dealing with a DROP only after it's happened is pretty limiting;
> (2) allowing user-defined code to run mid-command is dangerous.
> What's at issue is the tradeoff we make between these inescapable
> facts, and I'm not sure if we can get consensus on that.
>
> On the whole, though, I'm thinking that the approach Robert suggests
> is the way to go, because it doesn't foreclose our doing something
> else later.  Whereas if we ship 9.3 with a mid-DROP event, and we then
> find out that it's even more dangerous than we currently realize,
> we're going to be between a rock and a hard place.

The good news is that the patch to do that has already been sent on this
list, and got reviewed in details by Álvaro who did offer incremental
changes. Version 3 of that patch is to be found in:
 http://www.postgresql.org/message-id/m2fw19n1hr.fsf@2ndQuadrant.fr

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: scanner/parser minimization
Next
From: Andrew Dunstan
Date:
Subject: Re: Building on MinGW