On 2013-01-17 23:48:23 +0100, Dimitri Fontaine wrote: > Tom Lane <t...@sss.pgh.pa.us> writes: > > Alternatively, if you want to get something into 9.3 that has not > > necessarily got a long-term-stable API, I'd be inclined to suggest that > > we forget about a SQL-level event trigger facility for now, and just put > > in some hook call points. It's pretty well established that we're > > willing to change the API seen by hook functions across major releases. > > Or just a hook. That would want to have about the exact same amount of > information as the Event Trigger anyway, so I'm thinking we could maybe > do that the same way as the parsetree exposure? > > Another idea would be yet another GUC, ala allow_system_table_mods, so > that only intrepid users can have at it. Well, as long as the logical > replication use case is covered, I'm done here, so I want to hear from > Simon and Andres on that (and maybe the Slony and Londiste guys, etc), > and from you to triage what is possible and what is crazy.
> > TBH this might be the best thing anyway if your long-term goals have to > > do with replication, because it'd be a lot cheaper to get to the point > > where you could write the replication code and see if it all actually > > works. I'm fairly concerned that we might spend many man-months getting > > event triggers with definitions A,B,C into the system, only to find out > > later that what is really needed for logical replication is definitions > > D,E,F. 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. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
