"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes:
> Perhaps Oliver's suggestion of removing the link between logical and
> physical field ordering might help. That could lead to some interesting
> storage optimizations, as well. Collecting all variable types to the
> end of a tuple, for example, might be a win.
I recall seeing comments in the source to the effect that this was
considered (but never implemented) long ago. It does seem like a
very clean solution to some aspects of the add/drop column problem;
but implementation would be a pain in the neck. We'd have to go through
all of the source code and decide whether each use of an attribute
number should be using logical or physical number. It'd be a long slog.
It occurs to me that in at least some of the places where attribute
numbers are currently used, we ought to use *neither* logical nor
physical column position, but rather a permanent unique ID --- the
attribute tuple's OID would work, if it's assigned soon enough to be
used for constraints given in CREATE TABLE. (Otherwise we could assign
"column serial numbers" that count from 1 for each relation, but are
never changed or recycled within the relation.)
In particular, if parsetrees for stored rules and constraints worked
that way, renumbering attributes that follow the added/dropped column
would become a lot less painful.
regards, tom lane