This is along the lines of what I was talking about. If at compile time a user
could chose their on disk representation by version within a reasonable history
(say two major versions back) then I that would give people a choice for a
certain about of time.
Backward compatibility is nice but at a certain point it will become "backward"
(or better yet awkward or maybe just damn near impossible) to support certain
past features.
This is a user reality, upgrades are part of owning and using any system. Its
just that we don't want to seemingly force people to upgrade. I don't think
that is hard for someone that 24/7 shop with very large databases to understand.
Quoting Ron Johnson <ron.l.johnson@cox.net>:
> On Wed, 2003-09-17 at 03:45, Kaare Rasmussen wrote:
> [snip]
> > 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 least try to get the on-disk changes ready for 7.5 - with or
> without
> > the functionality to use it. I think that any pg_* table changes could be
> > done with a small and efficient pg_upgrade.
> [snip]
>
> I think changes in the system catalog should be separated from
> changes in the physical on-disk structures (i.e. how tables and
> indexes are stored).
>
> Maybe I'm totally wrong, but ALTERing the pg_* tables during each
> version upgrade should be relatively easy to script, when the phys-
> ical on-disk structures have been solidified.
>
> --
> -----------------------------------------------------------------
> Ron Johnson, Jr. ron.l.johnson@cox.net
> Jefferson, LA USA
>
> The difference between drunken sailors and Congressmen is that
> drunken sailors spend their own money.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
--
Keith C. Perry
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com
____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com