On 2012-12-29 09:59:49 -0500, Stephen Frost wrote:
> * Dimitri Fontaine (dimitri@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