Tom, I for one appreciate the fact that the developers would rather spend
their time working on features! Keep at it, everyone is doing a *great*
job. Postgres is a joy to use.
I don't really know what all the controversy is over here. Dumping your
data before a version upgrade of your database is pretty standard
procedure.
To the People Who Don't Backup Their Data Before Upgrading: you're playing
with fire. Even if you have some application which claims that you don't
need to dump your db and back it up, you're STILL playing with fire.
-----------------------------------------
Water overcomes the stone;
Without substance it requires no opening;
This is the benefit of taking no action.
Lao-Tse
Brian Knox
Senior Systems Engineer
brian@govshops.com
On Tue, 29 Aug 2000, Tom Lane wrote:
> teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
> > Tom Lane <tgl@sss.pgh.pa.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
>