Upgrading (was: now 6.4) - Mailing list pgsql-hackers

From Brandon Ibach
Subject Upgrading (was: now 6.4)
Date
Msg-id 199806120347.WAA25832@vweb.infomansol.com
Whole thread Raw
Responses Re: [HACKERS] Upgrading (was: now 6.4)  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
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 :)

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: inlining
Next
From: dg@illustra.com (David Gould)
Date:
Subject: Re: [HACKERS] inlining