Re: pg_migrator issue with contrib

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. +