Re: sql_drop Event Trigger

On Tue, Feb 5, 2013 at 10:42 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> A larger issue with the patch is handling of subxacts. A quick test
> doesn't reveal any obvious misbehavior, but having the list of objects
> dropped by a global variable might be problematic. What if, say, the
> event trigger function does something funny in an EXCEPTION block and it
> fails? Some clever test case is needed here, I think. Also, if we
> reset the variable at EOXact, do we also need to do something at
> EOSubXact?

This is an awfully good point, although I think the issue has to do
with command boundaries more than subtransactions. Suppose you create
two ddl_command_end event triggers, A and B. A contains a DROP IF
EXISTS command. Someone runs a toplevel DROP command. Now, A is
going to fire first, and that's going to recursively invoke A (which
will do nothing the second time) and then B; on return from B, we'll
finish running the event triggers for the toplevel command, executing
B again. If the list of dropped objects is stored in a global
variable, it seems like there are a number of ways this can go wrong.

I have not tested the actual behavior of the latest patch, but I think
we want to define things so that the
pg_event_trigger_dropped_objects() function returns, specifically, the
list of objects dropped by the command which caused the event trigger
to fire. In other words, in the above example, the first, recursive
invocation of B should see the object removed by A's DROP-IF-EXISTS,
and the second invocation should see the object removed by the
toplevel command.

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