Re: pg_migrator issue with contrib

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