On 2012-12-29 09:59:49 -0500, Stephen Frost wrote: > * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote: > > It sounds to me like either autonomous transaction with the capability > > to run the independant transaction in another database, or some dblink > > creative use case. Another approach would be to get plproxy into core > > as a Foreign Data Wrapper for FOREIGN FUNCTION that would target > > PostgreSQL. > > > > Given that, we could maybe have an internal setup that allows us to run > > foreign functions in the postgres database from any other one, providing > > what we need for Global Event Triggers. > > Of those, I'd think autonomous transactions is by far the most likely > and also useful for other sitatuions. I don't see dblink or plproxy > being used for this. Having some internal setup which allows us to run > foreign functions in other databases seems more-or-less akin to > autonomous transactions also.
I don't think autonomous transactions are the biggest worry here. Transactions essentially already span multiple databases, so thats not really a problem in this context. Making it possible to change catalogs while still being active in another database seems *far* harder. To the point where I would say its not really feasible. A shared table for event triggers sounds like it would be the far easier solution (9.4+ that is). 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