Tom Lane wrote: > Magnus Hagander <mag...@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 <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
