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] EnterpriseDB http://www.enterprisedb.com + 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 match
