> On Fri, 10 Dec 1999, Thomas Lockhart wrote:
>
> > imo the *only* reason we are tempted to do more major releases is that
> > we are too lazy/understaffed/sensible (you pick it) to support
> > multiple db formats for our compiled code. Other commercial DBs don't
> > release often, and they don't include big improvements, but they *do*
> > include support for multiple db formats/schemas in their product, so
> > you aren't forced into an initdb for each release. Instead they
> > include klugy workaround code to allow reading older formats with the
> > newer version.
>
> Then why don't we come up with something to autoconvert the user's
> databases without having to dump/initdb/reload? Or is that just
> not feasable (impossible's an answer I'd find hard to believe, but
> more trouble than it's worth is understandable).
System table changes often make that difficult. pg_upgrade does most of
what we want by keeping the disk tables and allowing initdb. If we
don't change the on-disk structure of user tables, pg_upgrade allows
quick upgrades. Not sure 7.0 will allow the use of pg_upgrade. 6.5 did
not because the on-disk table structure changed with MVCC.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
