Andrew Dunstan wrote:
> > Now, we are rewriting the table from scratch anyway, the on disk
> > format is changing. What is stopping us from switching the column
> > order at the same time. The only thing I can think is that the
> > catalogs will need more work to update them. It's a middle sized
> > price to pay for being able to reorder the columns in the table. One
> > of the problems I have is wanting to add a column in the middle of the
> > table, but FK constraints stop me dropping the table to do the
> > reorder. If ALTER TABLE would let me stick it in the middle and
> > rewrite the table on disk, I wouldn't care. It's likely that I would
> > be rewriting the table anyway. And by specifying AT POSITION, or
> > BEFORE/AFTER you know for big tables it's going to take a while.
> >
>
> This isn't really a compromise. Remember that this discussion started
> with consideration of optimal record layout (minimising space use by
> reducing or eliminating alignment padding). The above proposal really
> does nothing for that.
I assume space waste will be mostly fixed when we have 0/1 byte headers
for varlena data types.
-- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +