Bruce Momjian <br...@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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
