Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > I think the cleanest solution is to document that these issues might > > happen and suggest solutions. > > No, the cleanest solution is to fix it before people ever see a > problem. This is trivial to do in the case of dblink and I don't > see why you think it would be better to make users work around it. > > Also, dblink is one of the easiest cases because (a) it doesn't have > anything but functions, and thus it's possible to drop it from the > old DB without data loss, and (b) the inconsistency that it has is > something that will result in a clean, readily understandable failure > during migration. As opposed to some other cases that will migrate > just fine and then dump core during use. > > I've just finished running through a diff of 8.3 vs 8.4 contrib > SQL files. It looks like we have these cases:
[ list removed] Certainly if you can fix /contrib problems at the source, please do so. I was commenting on the idea of having pg_migrator somehow skip specific items to try to make it more failure-proof. While I can do that for a few cases, such as suppress the creation of specific functions by filtering the schema dump file, I will never be able to get them all, and doing it extensively could destabilize pg_migrator. You are suggesting improving /contrib itself, which is better. -- 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
