Yes, it would need to work as you describe below. Such a scheme is used
in several object databases I know of. (Versant being one) where it
works great. It's not just useful for drop column, but also things like
add column with default value. It means that you can add and drop
columns to your hearts content in the blink of an eye, and yet
ultimately not pay the price in terms of storage costs.
But yep, it's a lot more work, and understandable if there isn't
enthusiasm for doing it.
Tom Lane wrote:
>
> Chris Bitmead <chris@bitmead.com> writes:
> > I don't know if this is one of the 5, but my idea of a good
> > implementation is to do the fast invisible approach, and then update
> > individual tuples to the new format the next time they happen to be
> > UPDATEd.
>
> How would you tell whether a particular tuple has been updated or not?
>
> Furthermore, how would you remember the old tuple format (or formats)
> so that you'd know how to make the conversion?
>
> Seems to me this approach would require adding some sort of table
> version number to every tuple header, plus storing a complete set of
> system catalog entries for every past version of each table's schema.
> That's a heck of a high price, in both storage and complexity, for a
> feature of dubious value...
