| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: sql_drop Event Trigger |
| Date: | 2013-02-06 14:40:38 |
| Message-ID: | 20130206144038.GD4299@alvh.no-ip.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dimitri Fontaine escribió:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > 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.
Not sure about that. If the trigger records objects dropped in a table,
aren't they going to show up there twice if you do that?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2013-02-06 14:43:06 | Re: get_progname() should not be const char *? |
| Previous Message | Robert Haas | 2013-02-06 14:40:37 | Re: palloc unification |