Re: Proposal: In-Place upgrade concept

Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> It is not downgrade. It is about keep old structure until user says
> convert to the new data structure.

As Martijn already pointed out, the odds of problems surfacing only
after that conversion starts seem high enough to render the whole idea
a bit pointless. IMHO it's not worth the enormous development costs
it will add ... and it's *certainly* unwise to tie success of the
entire in-place-upgrade project to that one feature.

The attractive point about pg_migrator plus page-at-a-time data upgrade
is that it'd solve 90% of the problem with 10% of the work. If you get
that going, and people get accustomed to working with the development
restrictions associated with data upgradability, then you might be able
to come back and make a case for catalog upgradability and/or
downgradability in some future version. But right now you're asking
people to do 90% of the work before having anything at all.

> I do not expect that old code will work with new index structure. I want
> to keep both implementation and old index will be processed by old code
> and new one will be processed by new implementation. Each will have
> different OID and pg_class.relam will point to correct implementation.

I don't think it's quite that easy when you consider user-defined
datatypes. Where are you going to get two sets of opclasses from?

regards, tom lane