Re: pg_migrator issue with contrib

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...

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