Re: pg_migrator issue with contrib
От | Dimitri Fontaine |
---|---|
Тема | Re: pg_migrator issue with contrib |
Дата | |
Msg-id | 87skiahi48.fsf@hi-media-techno.com обсуждение исходный текст |
Ответ на | 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 <tgl@sss.pgh.pa.us> writes: > Dimitri Fontaine <dfontaine@hi-media.com> writes: >> 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. > > No, that's not what's being discussed. The proposal is to have it error > out when it *does not* know whether there is a real problem; and, in > fact, when there's only a rather low probability of there being a real > problem. My view is that that's basically counterproductive. It leads > directly to having to have a --force switch and then to people using > that switch carelessly. True, it could be that the data type representation has not changed between 8.3 and 8.4, nor the index content format. In this case pg_migrator will work fine on the cluster as soon as you installed the new .so... So the case where pg_migrator still fails is when the .sql file of the module has changed in a way that restoring what pg_dump gives no longer match what the .so exposes, or if the new .so is non backward compatible? Ok, maybe there's a way it'll just work. I withdraw my vote. Thanks for your patience, regards, -- dim
В списке pgsql-hackers по дате отправления: