On Wed, Feb 6, 2013 at 9:36 AM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> variable, it seems like there are a number of ways this can go wrong. > > Yeah, I think the current behavior might be surprising. > >> 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. > > I disagree with that. I don't see why the enclosing event trigger > shouldn't be aware of all the objects dropped by the command that just > ran to completion, *including* the effects of any event trigger fired > recursively or not.
Well, that could result in some DROP events being reported more than once, which I assume would be undesirable for someone hoping to use this for replication. (Eventually, we'll have to face the same problem for CREATE events, too.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
