Re: pg_migrator issue with contrib
От | Magnus Hagander |
---|---|
Тема | Re: pg_migrator issue with contrib |
Дата | |
Msg-id | 4A2D1B4B.7090209@hagander.net обсуждение исходный текст |
Ответ на | Re: pg_migrator issue with contrib (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_migrator issue with contrib
Re: pg_migrator issue with contrib |
Список | pgsql-hackers |
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. Doing them as two steps is totally fine with me, because IIRC the PostGIS upgrades generally don't require hours and hours of downtime. >>> 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. Well, in that case, error out would be a better option than doing it and probably fail later. And have a --force option available, but don't suggest it. //Magnus
В списке pgsql-hackers по дате отправления: