Re: pg_migrator issue with contrib

Magnus Hagander wrote:
> Dimitri Fontaine wrote:
> > Le 6 juin 09 ? 20:45, Josh Berkus a ?crit :
> >> So, here's what we need for 8.3 --> 8.4 for contrib modules:
> > 
> > That does nothing for external modules whose code isn't in PostgreSQL
> > control. I'm thinking of those examples I cited up-thread --- and some
> > more. (ip4r, temporal, prefix, hstore-new, oracfe, etc).
> 
> For me and I know several others, the big question would be PostGIS.
> Unfortunately I haven't had the time to run any tests myself, so I'll
> join the line of people being worried, but I have a number of customers
> with somewhere between pretty and very large PostGIS databases that
> could really benefit from pg_migrator.
> 
> 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)

Yes, it should work with the same version of PostGIS, but I have not
tested it.  There is nothing special about PostGIS that would cause it
not work work --- we use the same pg_dump as you would for a major
upgrade --- we just move the files around instead of dumping the data.

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

Right now pg_migrator throws an error if the schema load doesn't work. 
Assuming you use the same version on the old and new clusters, it should
work fine.  I am unclear what checking oids would do.

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