Re: Command Triggers, patch v11

Thom Brown <thom@linux.com>

From: Thom Brown <thom@linux.com>

To: Dimitri Fontaine <dimitri@2ndquadrant.fr>

Cc: pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>

Date: 2012-03-06T21:18:58Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix SPGiST vacuum algorithm to handle concurrent tuple motion properly.
- b4af1c25bbc6 9.2.0 cited
Remove useless const qualifier
- 66f0cf7da8ee 9.2.0 cited
Make executor's SELECT INTO code save and restore original tuple receiver.
- dfd26f9c5f37 9.2.0 cited

On 6 March 2012 21:04, Dimitri Fontaine <dimitri@2ndquadrant.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