| 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 |