Re: pg_migrator issue with contrib
От | Dimitri Fontaine |
---|---|
Тема | Re: pg_migrator issue with contrib |
Дата | |
Msg-id | 874ouqiymy.fsf@hi-media-techno.com обсуждение исходный текст |
Ответ на | Re: pg_migrator issue with contrib (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: pg_migrator issue with contrib
Re: pg_migrator issue with contrib |
Список | pgsql-hackers |
Magnus Hagander <magnus@hagander.net> writes: > Tom Lane wrote: >> Magnus Hagander <magnus@hagander.net> writes: >>>> 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. My vote would go to detect and error out without recovering option. If the tool is not able to handle a situation and knows it, I don't see what would be good about it leting the user lose data on purpose. The --force option should be for the user to manually drop his columns and indexes (etc) and try pg_migrator again, which will stop listing faulty objects but care about the now compatible cluster. Restoring the lost data is not the job of pg_migrator, of course. Regards, -- dim
В списке pgsql-hackers по дате отправления: