Re: pg_migrator issue with contrib
От | Magnus Hagander |
---|---|
Тема | Re: pg_migrator issue with contrib |
Дата | |
Msg-id | 4A2CC9A3.8000301@hagander.net обсуждение исходный текст |
Ответ на | Re: pg_migrator issue with contrib (Dimitri Fontaine <dfontaine@hi-media.com>) |
Ответы |
Re: pg_migrator issue with contrib
Re: pg_migrator issue with contrib |
Список | pgsql-hackers |
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) > 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. -- Magnus HaganderSelf: http://www.hagander.net/Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: