Re: [HACKERS] ALTER TABLE DROP COLUMN

Tom Lane wrote:
> 
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > You can exclusively lock the table, then do a heap_getnext() scan over
> > the entire table, remove the dropped column, do a heap_insert(), then a
> > heap_delete() on the current tuple, making sure to skip over the tuples
> > inserted by the current transaction.  When completed, remove the column
> > from pg_attribute, mark the transaction as committed (if desired), and
> > run vacuum over the table to remove the deleted rows.
> 
> Hmm, that would work --- the new tuples commit at the same instant that
> the schema updates commit, so it should be correct.  You have the 2x
> disk usage problem, but there's no way around that without losing
> rollback ability.
> 
> A potentially tricky bit will be persuading the tuple-reading and tuple-
> writing subroutines to pay attention to different versions of the tuple
> structure for the same table.  I haven't looked to see if this will be
> difficult or not.  If you can pass the TupleDesc explicitly then it
> shouldn't be a problem.
> 
> I'd suggest that the cleanup vacuum *not* be an automatic part of
> the operation; just recommend that people do it ASAP after dropping
> a column.  Consider needing to drop several columns...

Does SQL92 syntax allow dropping several columns, i.e.

ALTER TABLE mytable DROP COLUMN col1,col5,col6;

If it does, it would be very desirable to implement it to avoid the need 
for vacuum between each DROP in order to have _only_ 2X disk usage.

-----------
Hannu