Dimitri Fontaine wrote: > Tom Lane <t...@sss.pgh.pa.us> writes: > > > Dimitri Fontaine <dfonta...@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...
Yes. > 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? Yes, that is a problem. It is not a pg_migrator-specific problem because people traditionally bring the /contrib schema over from the old install (I think). The only pg_migrator-specific failure is when the data format changed and dump/restore would fix it, but pg_migrator would migrate corrupt data. :-( -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
