On Thu, Apr 25, 2002 at 02:27:42AM -0400, Craig Isdahl wrote:
> Why does the on disk format of postgres change between major (not
> sure if that's the right terminology) releases? Benefits?
> Drawbacks?
Actually, it's not the on-disk format that keeps changing. In fact, the same
basic format was used for at least 6.5-7.1. What changed is the system
schema. Since the structure of the schema on disk is reflected in the
binary, these are bound (you could argue this is an optimisation).
For example, 7.0 added support for foreign keys. This required some new
tables and a few columns in pg_class. 7.1 added TOAST support, which also
required some new fields. 7.2 changed the names of the files on disk so that
DROP TABLE could be safely rolled back.
They're not changing the format on a whim, but they are required to support
new feature. Implementing backward compatability here would be quite
difficult. Note also that they are very careful about preserving structure
within minor releases.
> As someone new to the "scene" the thought of "dumping" databases,
> running initdb, then restoring the databases is... umm... (looking
> for the right word)... daunting/scary/silly. Especially for
> production dbs.
Which is why production databases sometimes lag a version behind. _Working_
is more important than _latest_. Not to mention that you can do it with no
risk to data. And everyone has backups, right?
> However, I've also noticed that many on this list are running some
> "serious" postgres installations and this apparently isn't a
> concern, so I thought I'd ask.
You are free to implement a backward compatability layer if you wish. Though
I think you underestimate the amount of work involved.
HTH,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Canada, Mexico, and Australia form the Axis of Nations That
> Are Actually Quite Nice But Secretly Have Nasty Thoughts About America
