On Fri, 19 Sep 2003, Tom Lane wrote:
> Manfred Koizar <mkoi-pg@aon.at> writes:
> > Elsewhere in this current thread it has been suggested that the
> > on-disk format will stabilize at some time in the future and should
> > then be frozen to ensure painless upgrades. IMHO, at the moment when
> > data structures are declared stable and immutable the project is dead.
>
> This is something that concerns me also.
But, is there anything wrong with striving for something you mentioned
earlier ... "spooling" data structure changes so that they don't happen
every release, but every other one, maybe?
> > ... But once the infrastructure is in place, things
> > should get easier.
>
> Until we have a working pg_upgrade, every little catalog change will
> break backwards compatibility. And I do not feel that the appropriate
> way to handle catalog changes is to insist on one-off solutions for each
> one. Any quick look at the CVS logs will show that minor and major
> catalog revisions occur *far* more frequently than changes that would
> affect on-disk representation of user data. If we had a working
> pg_upgrade then I'd be willing to think about committing to "no user
> data changes without an upgrade path" as project policy. Without it,
> any such policy would simply stop development in its tracks.
hmmm ... k, is it feasible to go a release or two at a time without on
disk changes? if so, pg_upgrade might not be as difficult to maintain,
since, unless someone an figure out a way of doing it, 'on disk change
releases' could still require dump/reloads, with a period of stability in
between?
*Or* ... as we've seen more with this dev cycle then previous ones, how
much could be easily back-patched to the previous version(s) relatively
easily, without requiring on-disk changes?