From: | Thom Brown <thom(at)linux(dot)com> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Command Triggers, patch v11 |
Date: | 2012-03-06 21:18:58 |
Message-ID: | CAA-aLv5-KAMD_PMEUK=SiG_OBdM4jiQ3O=kpw8fZM+-Uq4PJ1g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6 March 2012 21:04, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
>>> [CASCADE will not run the command triggers for cascaded objects]
>> If these are all expected, does it in any way compromise the
>> effectiveness of DDL triggers in major use-cases?
>
> I don't think so. When replicating the replica will certainly drop the
> same set of dependent objects, for example. Auditing is another story.
> Do we want to try having cascaded object support in drop commands?
I wasn't sure if auditing was one of the rationale behind the feature
or not. If it is, it presents a major problem. How does the replica
know that the objects were dropped?
Thanks for the updated patch and the quick turnaround time. I'll give
it another review.
--
Thom
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2012-03-06 21:26:15 | Re: How to know a table has been modified? |
Previous Message | Robert Haas | 2012-03-06 21:15:57 | Re: Dropping PL language retains support functions |