Re: sql_drop Event Trigger - Mailing list pgsql-hackers

On Wed, Feb 6, 2013 at 12:28 PM, Christopher Browne <cbbrowne@gmail.com> wrote:
> On Wed, Feb 6, 2013 at 12:05 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> 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?
>
> In this case, the "hygenic" change that we're thinking of making to Slony,
> at least initially, is for the trigger to check to see if the table is
> replicated,
> and raise an exception if it is.
>
> That forces the Gentle User to submit the Slony SET DROP TABLE
> command <http://slony.info/documentation/2.1/stmtsetdroptable.html>.
>
> Now, if we stipulate that imposition, then, for this kind of event, it
> becomes unnecessary for event triggers to get *overly* concerned about
> capturing more about dropping tables.  After all, SET DROP TABLE
> already knows how to replicate its action, so what happens, in that
> case is:
>
> - User submits SET DROP TABLE
>    - SET DROP TABLE drops the triggers for the table, cleans out
>      Slony configuration surrounding the table, forwards request
>      to other nodes
>
> - User submits DROP TABLE
>    - Slony is no longer involved with that table; there's nothing special
>      anymore about replicating this; perhaps we capture and forward
>      it via event trigger.
>
> I'm not sure if that makes thinking about this easier, I hope so :-).

Well, that means you wouldn't necessarily mind getting duplicate DROP
events for the same object, but they don't benefit you in any way,
either.  And, I'm not sure we can conclude from this that duplicate
events will be OK in every use case.  For example, for a logging hook,
it's pessimal, because now you're logging duplicate messages for the
same drops and there's no easy way to fix it so you don't.

Also, it means you're really going to need the schema name and table
name for this to be useful; Tom was just complaining upthread that
without that information the features isn't useful, so perhaps we
should conclude from your email that he is correct.

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