Re: State of Beta 2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Manfred Koizar <mkoi-pg(at)aon(dot)at>
Cc: Lamar Owen <lowen(at)pari(dot)edu>, "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Dennis Gearon <gearond(at)fireserve(dot)net>, Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>, PgSQL General ML <pgsql-general(at)postgresql(dot)org>
Subject: Re: State of Beta 2
Date: 2003-09-19 21:38:13
Message-ID: 9097.1064007493@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Manfred Koizar <mkoi-pg(at)aon(dot)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.

> A working pg_upgrade is *not* the first thing we need.

Yes it is. As you say later,

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

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2003-09-19 21:41:06 Re: Rockets (was Re: PostgreSQL versus MySQL)
Previous Message Tom Lane 2003-09-19 21:30:29 Re: Identify dropped columns in PLTCL