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
