Kaare Rasmussen <kar@kakidata.dk> writes:
> Some people have claimed that the big commercial databases don't change their
> on-disk represantation anymore. Maybe PostgreSQL could try to aim for this
> goal.
At the very least we could try to quantize changes --- say, allow
on-disk changes only every third or fourth major release, and batch up
work requiring such changes. Avoiding on-disk changes actually was a
design consideration for awhile, but we sort of stopped worrying about
it when the prototype version of pg_upgrade stopped working (which IIRC
was because it couldn't get at what it would need to get at without
being rewritten in C, and no one wanted to tackle that project).
> How do other Open Source systems do ? MySQL (or maybe better: InnoDB),
> FireBird ??
Dunno about MySQL. I'm pretty sure I remember Ann Harrison stating that
FireBird's disk structures haven't changed since the beginning of
Interbase. Which you might take as saying that they were a lot smarter
than we are, but I suspect what it really means is that
FireBird/Interbase hasn't undergone the kind of metamorphosis of purpose
that the Postgres code base has. Keep in mind that it started as an
experimental academic prototype (representing some successful ideas and
some not-so-successful ones), and the current developers have been
laboring to convert it into an industrial-strength production tool ---
keeping the good experimental ideas, but weeding out the bad ones, and
adding production-oriented features that weren't in the original design.
The entire argument that version-to-version stability should be a
critical goal would have been foreign to the original developers of
Postgres.
regards, tom lane
