Thread

1. Upgrading (was: now 6.4)

   Brandon Ibach <bibach@infomansol.com> — 1998-06-12T03:47:34Z

      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 :)
   
   

2. Re: [HACKERS] Upgrading (was: now 6.4)

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-06-12T04:40:25Z

   > 
   >    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)