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 will
exit and you will have to revert to the old cluster as outlined in step
#10 below. To try pg_migrator again, you will need to modify the old
cluster so the pg_migrator schema restore succeeds. If the problem is a
/contrib module, you might need to uninstall the /contrib module from
the 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 <[email protected]> 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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
