Re: sql_drop Event Trigger - Mailing list pgsql-hackers

From Robert Haas
Subject Re: sql_drop Event Trigger
Date
Msg-id CA+TgmoYLO=GLJhtDXL6FSzsD9BQD44P3vw67kGyTKjeRc7S3Jw@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
List pgsql-hackers
On Wed, Feb 6, 2013 at 9:36 AM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Robert Haas <robertmhaas@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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: palloc unification
Next
From: Robert Haas
Date:
Subject: Re: palloc unification