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   [EMAIL PROTECTED]

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to