Re: Event Triggers: adding information
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Dimitri Fontaine <dimitri@2ndQuadrant.fr>, Simon Riggs <simon@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2013-01-18T02:48:01Z
Lists: pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes: > I have no problem requiring C code to use the even data, be it via hooks > or via C functions called from event triggers. The problem I have with > putting in some hooks is that I doubt that you can find sensible spots > with enough information to actually recreate the DDL for a remote system > without doing most of the work for command triggers. "most of the work"? No, I don't think so. Here's the thing that's bothering me about that: if the use-case that everybody is worried about is replication, then triggers of any sort are the Wrong Thing, IMO. The difference between a replication hook and a trigger is that a replication hook has no business changing any state of the local system, whereas a trigger *has to be expected to change the state of the local system* because if it has no side-effects you might as well not bother firing it. And the fear of having to cope with arbitrary side-effects occuring in the midst of DDL is about 80% of my angst with this whole concept. If we're only interested in replication, let's put in some hooks whose contract does not allow for side-effects on the local catalogs, and be done. Otherwise we'll be putting in man-years of unnecessary (or at least unnecessary for this use-case) work. regards, tom lane