Re: sql_drop Event Triggerg

On Wed, Mar 20, 2013 at 5:42 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Here's a new version of this patch, rebased on top of the new
> pg_identify_object() stuff. Note that the regression test doesn't work
> yet, because I didn't adjust to the new identity output definition (the
> docs need work, too). But that's a simple change to do. I'm leaving
> that for later.

I think this is getting there. A few things to think about:

- pg_event_trigger_dropped_objects seems to assume that
currentEventTriggerState will be pointing to the same list on every
call. But is that necessarily true? I'm thinking about a case where
someone opens a cursor in an event trigger and then tries to read from
that cursor later in the transaction. I think you might be able to
crash the server that way.

- I am not wild about the idea of propagating PG_TRY/PG_CATCH blocks
into yet more places. On Linux-x86 they are pretty cheap because
Linux doesn't need a system call to change the signal mask and x86 has
few registers that must be saved-and-restored, but elsewhere this can
be a performance problem. Now maybe ProcessUtility is not a
sufficiently-frequently called function for this to matter... but I'm
not sure. The alternative is to teach the error handling pathways
about this in somewhat greater detail, since the point of TRY/CATCH is
to cleanup things that the regular error handling stuff doesn't now
about.

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