Re: pg_migrator issue with contrib

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Dimitri Fontaine wrote:
> >> So the case where pg_migrator still fails is when the .sql file of the
> >> module has changed in a way that restoring what pg_dump gives no longer
> >> match what the .so exposes, or if the new .so is non backward
> >> compatible?
> 
> > Yes, that is a problem.  It is not a pg_migrator-specific problem
> > because people traditionally bring the /contrib schema over from the old
> > install (I think).  The only pg_migrator-specific failure is when the
> > data format changed and dump/restore would fix it, but pg_migrator would
> > migrate corrupt data.  :-(
> 
> There is a different problem though: sometimes the recommended fix for
> contrib-module incompatibilities is to load the new contrib module into
> the target database before trying to load your old dump file.  (We told
> people to do that for 8.2->8.3 tsearch2, for example.)  In the
> pg_migrator context there is no way to insert the new contrib module
> first, and also no way to ignore the duplicate-object errors that you
> typically get while loading the old dump.
> 
> It would probably be a relatively simple feature addition to teach
> pg_migrator to load such-and-such modules into the new databases before
> loading the old dump.  But I'm still scared to death by the idea of
> letting it ignore errors, so there doesn't seem to be any good solution
> to this type of migration scenario.

Ah, OK, interesting.  We could have pg_migrator detect this issue and
fail right away with a message indicating pg_migrator cannot be used
unless those objects are dumped manually and the /contrib removed.

As long as pg_migrator is clear, I don't think people will complain.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +