On Mon, Nov 15, 2010 at 12:41 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> Looking through the code, it appears to me that we'd need to do the >> following (not necessarily in this order): > > Don't forget > > 9. Unload loadable modules that do not exist according to the new > database's catalogs; eg we don't want postgis trying to run when > its supporting tables don't exist in the selected database.
I might be missing something here, but I wasn't aware that the catalogs had any say in what loadable modules exist. Obviously their contents will determine whether such loadable modules ever get invoked as a result of actions at the SQL level, but if they don't it may not matter much that they're loaded but idle. > 10. Somehow persuade remaining loadable modules to discard whatever > state they have that might be database-local. Ouch. > We don't have workable APIs for either of those operations ATM. Somewhat independently of this problem, it would be nice to be able to unload a loadable module, and I think that we currently don't support that at all. One thing (the only thing?) that makes that a show-stopper is that the way we manage hook function chaining makes it impossible for a module to reliably unload itself. If you load both auto_explain and pg_stat_statements, for example, you end up with a tangle of pointers that can't be easily unwound. I don't have a real clear idea how to fix it, but the status quo certainly doesn't seem optimal. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
