Re: sql_drop Event Triggerg

On Tue, Mar 26, 2013 at 3:02 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> I tried this and it doesn't work. The "error pathways" you speak about
> would be the xact.c entry points to commit and abort transactions;
> however, there's a problem with that because some of the commands that
> ProcessUtility() deals with have their own transaction management
> calls internally; so those would call CommitTransaction() and the
> event trigger state would go away, and then when control gets back to
> ProcessUtility there would be nothing to clean up. I think we could
> ignore the problem, or install smarts in ProcessUtility to avoid calling
> event_trigger.c when one of those commands is involved -- but this seems
> to me a solution worse than the problem. So all in all I feel like the
> macro on top of PG_TRY is the way to go.

I see. :-(

> Now there *is* one rather big performance problem in this patch, which
> is that it turns on collection of object dropped data regardless of
> there being event triggers that use the info at all. That's a serious
> drawback and we're going to get complaints about it. So we need to do
> something to fix that.

Really? Who is going to care about that? Surely that overhead is
quite trivial.

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