Bruce Momjian wrote:
> > 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.
I have added the following paragraph to the pg_migrator INSTALL docs:
If an error occurs while restoring the database schema, pg_migrator willexit and you will have to revert to the old
clusteras outlined in step#10 below. To try pg_migrator again, you will need to modify the oldcluster so the
pg_migratorschema restore succeeds. If the problem is a/contrib module, you might need to uninstall the /contrib
modulefromthe old cluster and install it in the new cluster after migration.
The only other idea I have would be to add a switch that allows
schema restore errors to be ignored, but I would like to see if the
above text is enough first.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +