Re: pg_migrator issue with contrib

Dimitri Fontaine wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> > Dimitri Fontaine <dfontaine(at)hi-media(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +