| 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:44:52 |
| Message-ID: | m2sj59jycb.fsf@2ndQuadrant.fr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2013-02-06 14:59:47 | Re: palloc unification |
| Previous Message | Robert Haas | 2013-02-06 14:43:06 | Re: get_progname() should not be const char *? |