Skip site navigation (1) Skip section navigation (2)

Re: 7.1 Release Date

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: teg(at)redhat(dot)com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=)
Cc: The Hermit Hacker <scrappy(at)hub(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: 7.1 Release Date
Date: 2000-08-29 16:23:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
teg(at)redhat(dot)com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> You can always stick to Postgres 6.5 :-).  There are certain features
>> that just cannot be added without redoing the on-disk table format.
>> I don't think we will ever want to promise "no more dump/reload";
>> if we do, it will mean that Postgres has stopped improving.

> Not necesarrily - one could either design a on disk format with room
> for expansion or create migration tools to add new fields.

"Room for expansion" isn't necessarily the issue --- sometimes you
just have to fix wrong decisions.  The table-file-naming business is
a perfect example.

Migration tools might ease the pain, sure (though I'd still recommend
doing a full backup before a major version upgrade, just on safety
grounds; so the savings afforded by a tool might not be all that much).

Up to now, the attitude of the developer community has mostly been
that our TODO list is a mile long and we'd rather spend our limited
time on bug fixes and new features than on migration tools --- both
because it seemed like the right set of priorities for the project,
and because fixes/features are fun while tools are just work ;-).
But perhaps that is an area where Great Bridge and PostgreSQL Inc can
make some contributions using support-contract funding.

			regards, tom lane

In response to


pgsql-general by date

Next:From: Brook MilliganDate: 2000-08-29 16:28:43
Subject: Re: SQL scripts - sequences
Previous:From: Ange Michel POZZODate: 2000-08-29 16:11:24
Subject: Re: Re: [GENERAL] cannot vacuum a database !

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group