Andrew Dunstan wrote: > > > Bruce Momjian wrote: > >> At the very least, a mention in the documentation of incompatible > >> contrib module(s) would be nice. Even better would be a sanity check > >> added to prevent this. > >> > > > > OK, I am looking to the hackers group for recommentations on this. I > > wonder if I should recommend uninstalling /contrib modules before the > > upgrade, but that is not possible for custom data types that have > > columns already defined in the old cluster. > > > > > > There is no nice answer to this. It goes way beyond data types: you > could be using the module stuff in indexes, functions, views etc. You > can't just drop the stuff. The best I have been able to do in similar > cases is to install the updated module in the database before restoring, > and ignore any restoration errors about "foo already exists" or "foo not > found in .so file". Not sure how well that translates to pg_migrator, > though.
I suspected this answer but figured I would get a definative answer rather than guessing. Based on the way pg_migrator works I am going to suggest that if /contrib restore generates an error that they uninstall the /contrib from the old cluster and retry. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
