From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: sql_drop Event Trigger |
Date: | 2013-02-06 14:36:38 |
Message-ID: | m27gmlldah.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-02-06 14:38:35 | Re: palloc unification |
Previous Message | Robert Haas | 2013-02-06 14:28:29 | Re: palloc unification |