On Fri, Aug 9, 2013 at 8:44 AM, Stephen Frost wrote:
* Robert Haas (robertmhaas@gmail.com) wrote:
On Sun, Aug 4, 2013 at 4:26 PM, Dimitri Fontaine wrote:
What I'm yet unsure about is that there's a consensus that the use cases
are worthy of a new shared catalog in the system. Also I didn't look how
hard it is to actually provide for it.
A new shared catalog wouldn't actually help, because the actual
procedure to be run has to live in pg_proc, which is not shared. And
that has references to all sorts of other things (like pg_language)
that aren't shared either.
A shared catalog which defined which *database* to run the trigger in,
with a way to fire off a new backend worker in that database and tell it
to run the trigger, might be interesting and would deal with the issue
that the trigger would behave differently depending on the database
connected to. That would bring along other issues, of course, but it
seemed an interesting enough idea to mention.
Eh, maybe. I'm not sure there's enough use case for that to justify
the amount of infrastructure it would require. I'm happy with the
recent enhancements to background workers, but there's an awful lot of
ground to cover between that and what you're proposing.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2018 Grokbase