Re: pg_migrator issue with contrib
От | Bruce Momjian |
---|---|
Тема | Re: pg_migrator issue with contrib |
Дата | |
Msg-id | 200906081518.n58FIed05377@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_migrator issue with contrib (Dimitri Fontaine <dfontaine@hi-media.com>) |
Список | pgsql-hackers |
Dimitri Fontaine wrote: > >> 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. Agreed. Right now pg_migrator never modifies the old cluster except for renaming pg_control (documented) so the old cluster is not accidentally restarted. I don't want to change that behavior. I would filter the dump --schema file, but again, it is best to let the administrator do it, and if they can't, they should just do dump/restore. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: