Stephen Frost <sfrost@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
