Re: sql_drop Event Trigger - Mailing list pgsql-hackers

From Robert Haas
Subject Re: sql_drop Event Trigger
Date
Msg-id CA+TgmoYhWpHagd8R6ZG5AzY+PdMFsiUAqBLfynGfDejcdPgjRQ@mail.gmail.com
Whole thread Raw
In response to Re: sql_drop Event Trigger  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: sql_drop Event Trigger  (Christopher Browne <cbbrowne@gmail.com>)
List pgsql-hackers
On Wed, Feb 6, 2013 at 9:44 AM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>>> 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.
>
> Any command might have an event trigger attached doing a DROP, so that
> you don't know where to expect it, and it's well possible that in your
> example both the event triggers have been installed by different tools.

It certainly is; in fact, it's likely.  So let's say that B is a
replication trigger.  Don't you want it to hear about each drop
exactly once?  If not, how will you avoid errors when you go to replay
the events you've captured on another machine?

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



pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Alias hstore's ? to ~ so that it works with JDBC
Next
From: Phil Sorber
Date:
Subject: Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)