> That seems like pure speculation to me, if not outright wrong. If we
> can't renumber the attnums it'll be because the table's tuples still
> have data at a particular column position. Since we'll need to know
> the datatype of that data (if only to skip over it correctly), there
> will still have to be a pg_attribute entry for the dropped column.
> Thus, what people will more likely have to watch out for is pg_attribute
> rows marked "deleted" in some fashion.
You know there is a way to do this and not break client compatibility.
Rename the current pg_attribute relation to pg_baseatt or something. Fix
all references to it in the code. Create a system view called pg_attribute
which is SELECT * (except attisdropped) FROM pg_baseattr WHERE NOT
attisdropped.
More work though, of course.
> We are actually not that far away from being able to do DROP COLUMN,
> if people don't mind being slow to recover the space used by a dropped
> column. It'd work like this:
Logical vs. physical column numbers would still be quite handy tho. If
you're going to break compatibility, may as well do all breaks at once?
> 1. Add an "attisdropped" boolean to pg_attribute.
>
> 2. DROP COLUMN sets this flag and changes attname to something like
> "***deleted_NNN". (Changing attname is only necessary to allow the
> same column name to be reused without drawing a unique-index error.)
> That's it --- it's done.
>
> 3. Column lookup, expansion of *, etc have to be taught to ignore
> columns marked attisdropped.
>
> The idea is that the extant data sits there but is invisible. Inserts
> of new rows in the table would always insert a NULL in the dropped
> column (which'd fall out more or less for free, there being no way
> to tell the system to insert anything else). Over time, UPDATEs of
> extant rows would also replace the dropped data with NULLs.
Would it be possible to modify VACUUM FULL in some way so as to permanently
remove these tuples? Surely people would like an actual space-saving column
drop?
Chris
