Stephen Frost <sfr...@snowman.net> writes: > I disagree. If we're going to have what are essentially 'global' event > triggers, then they should go into a shared catalog- the user shouldn't > be required to install them everywhere to get coverage. In addition,
I understand your view point, and if we think we will be able to get that in the future, then I think we should be careful not to implement something else in the mean time. > they should always fire in the same database (eg: postgres), so you > could reasonably have a single log of 'CREATE DATABASE' commands being > run. Of course, then we get into the technical issues which prevent > that, such as having one backend connected to database xyz but needing > to run commands in the postgres database. > > So, for my 2c, I do think there's a technical challenge which would have > to be overcome to have global event triggers. 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. Oh, I don't see that happening in 9.3. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
