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.
10. Somehow persuade remaining loadable modules to discard whatever
state they have that might be database-local.
We don't have workable APIs for either of those operations ATM.
I believe also that there are probably race conditions in several of
the steps you listed; in particular there is certainly a risk involved
in changing the database-we-advertise-being-connected-to versus a
concurrent DROP DATABASE. Maybe that's easily soluble, but I'm not sure
about it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
