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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +