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