Tom Lane wrote:
> Bruce Momjian <bruce@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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +