Re: pg_migrator issue with contrib

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +