Re: pg_migrator issue with contrib

Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > As long as PostGIS is the same version in both of them, is pg_migrator
> > is likely to work? (one can always run the PostGIS upgrade as a separate
> > step)
> 
> There was just some discussion about that on postgis-devel.  I think the
> conclusion was that you would have to do the PostGIS update as a
> separate step.  They intend to support both 1.3.x and 1.4.x on current
> versions of Postgres for some time, so in principle you could do it in
> either order.

Oh, yea, you can't go from PostGIS version 1.3 to 1.4 _while_ you do the
pg_migrator upgrade.  It has to be done either before or after
pg_migrator is run.  I wonder how I could prevent someone from trying
that trick.

> >> Could pg_migrator detect usage of "objects" oids (data types in
> >> relation, index opclass, ...) that are unknown to be in the standard
> >> -core + contrib distribution, and quit trying to upgrade the cluster in
> >> this case, telling the user his database is not supported?
> 
> > +1 on this.
> 
> > Or at least, have it exit and say "if you know that these things are
> > reasonably safe, run pg_migrator again with --force" or something like that.
> 
> I don't think that anything in that line is going to be helpful.
> What it will lead to is people mindlessly using --force (cf our
> bad experiences with -i for pg_dump).  If you can't give a *useful*
> ie trustworthy warning/error, issuing a useless one is not a good
> substitute.

Yep.  The install instructions explain how you have to get around this,
and if they don't understand it, they shouldn't be using pg_migrator and
should just do the traditional dump/restore.  It is too tempting to give
them a force flag.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +