Tom Lane wrote: > 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.
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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
