Re: Changing data types

On Mon, 24 Sep 2001, Rod Taylor wrote:

> Out of curiosity how was option a) implemented? I could envision
> supporting multiple versions of a tuple style to be found within a
> table (each described in pg_attribute). Gradually these would be
> upgraded through normal use.
Check the archives (look for "DROP COLUMN" and "Hiroshi Inoue", author of
original patch).

> One would expect that keeping multiple versions of a tuple structure
> inside a single table to be slower than normal for selects, but I
> don't think it would require marking the rows themselves -- just base
> it on the max and min transactions in the table at that time. Vacuum
> would have to push the issue (5k tuples at a time?) of upgrading some
> of the tuples each time it's run in order to enfore that they were all
> gone before XID wrap. Background vacuum is ideal for that (if
> implemented). Drop all constraints, indexes and the name (change to
> $1 or something) of the column immediatly. Vacuum can determine when
> XID Min in a table is > XID Max of another version and drop the
> information from pg_attribute.
I think it was done by setting attribute_id to negative, essentially
hiding it from most code, instead of having two tuple versions, but I
really am not very familiar. Check archives :)

> Obviously affected:
> - pg_attribute, and anything dealing with it (add XID Max, XID Min
> wraps for known ranges)
> - storage machanism. On read of a tuple attempt to make it fit latest
> version (XID Max is NULL) by ignoring select fields.
>
> I'll have to leave it up to the pros as to whether it can be done,
> should be done, and what else it'll affect.
>
> I suppose this was option a) that was removed due to it's kludgyness
> :)