   I hate to open a potential can of worms here, but here's another
possibility.  I recall someone telling me about a database (InterBase,
I believe it was) that could have rows with different structures all
in the same table.  In other words, they could add a field to the
table, and any new rows would have it, while the old ones would not,
and the database would deal with it on the fly.
   Could we implement some type of "version" field in the table
structure which would allow this type of thing?  If this is
reasonable, we could have it in 6.4 and potentially never have to
worry too much about reloading tables after that.  With version info
in each tuple, we could convert the table "as we go" or in some other
gradual way.
   Of course, the question of how much work it would take to have the
backend support this needs to be considered, as well as the issue of
how this would impact performance.

-Brandon :)

Thu, 11 Jun 1998 22:47:34 -0500 (CDT)
Brandon Ibach <bibach@infomansol.com>
Upgrading (was: now 6.4)
> 
>    I hate to open a potential can of worms here, but here's another
> possibility.  I recall someone telling me about a database (InterBase,
> I believe it was) that could have rows with different structures all
> in the same table.  In other words, they could add a field to the
> table, and any new rows would have it, while the old ones would not,
> and the database would deal with it on the fly.
>    Could we implement some type of "version" field in the table
> structure which would allow this type of thing?  If this is
> reasonable, we could have it in 6.4 and potentially never have to
> worry too much about reloading tables after that.  With version info
> in each tuple, we could convert the table "as we go" or in some other
> gradual way.
>    Of course, the question of how much work it would take to have the
> backend support this needs to be considered, as well as the issue of
> how this would impact performance.

Actually, we already have that.  When you add a column to a table, it
does not re-structure the old rows.  However, system tables do not
always add columns.  Sometimes we change them.  Also there is lots
more/different rows for tables, and keeping that straight would be
terrible.

If we can keep the original data files and require initdb and a
re-index, that would be good.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Fri, 12 Jun 1998 00:40:25 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Upgrading (was: now 6.4)