Re: Column storage positions - Mailing list pgsql-hackers

From Robert Treat
Subject Re: Column storage positions
Date
Msg-id 200702201954.42880.xzilla@users.sourceforge.net
Whole thread Raw
In response to Column storage positions  ("Phil Currier" <pcurrier@gmail.com>)
List pgsql-hackers
On Tuesday 20 February 2007 16:07, Phil Currier wrote:
> Another problem relates to upgrades.  With tools like pg_migrator now
> on pgfoundry, people will eventually expect quick upgrades that don't
> require rewriting each table's data.  Storage positions would cause a
> problem for every version X -> version Y upgrade with Y >= 8.3, even
> when X is also >= 8.3, because a version X table could always have
> been altered without a rewrite into a structure different from what
> Y's CREATE TABLE will choose.  

If you are using pg_migrator your not going to be moving the datafiles on disk 
anyway,so pg_migrator's behavior shouldnt change terribly.  If your doing 
pg_dump based upgrade, presumably pg_dump could write it's create statements 
with the columns in attstorpos order and set attnum = attstorpos, preserving 
the physical layout from the previous install.

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL


pgsql-hackers by date:

Previous
From: "Sergey E. Koposov"
Date:
Subject: Re: Column storage positions
Next
From: Bruce Momjian
Date:
Subject: Re: timestamp subtraction (was Re: [SQL] formatting intervals with to_char)