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. +