Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > Tom Lane wrote: > >> 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. > > > 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. > > How would it detect it? I think the only thing you could do is > hard-wire tests for specific objects, which is klugy and doesn't > extend to third-party modules that you don't know about.
Yep, that is the only way. The good news is that we are not modifying any data so it is just a detection issue, i.e. it would not destabilize pg_migrator's operation. > In most cases where there are major incompatibilities, attempting to > load the old dump file would fail anyway, so I don't think pg_migrator > really needs any hard-wired test. It's the minor changes that are > risky. I think ultimately the burden for those has to be on the module > author: he has to either avoid cross-version incompatibilities or make > sure they will fail safely. Yep. -- 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
