Peter Eisentraut <peter_e@gmx.net> writes:
> Side idea: Let attnum be the logical number, introduce attphysnum as
> the storage position, and add an oid to pg_attribute as the eternal
> identifier.
> That way you avoid breaking pretty much all user code that looks at
> pg_attribute, which will probably do something like ORDER BY attnum.
> Also, one could get rid of all sorts of ugly code that works around the
> lack of an oid in pg_attribute, such as in the dependency tracking.
I think using an OID would break more stuff than it fixes in dependency
tracking; in particular you would now need an explicit dependency link
from each column to its table, because the "sub-object" knowledge would
no longer work. In any case this patch is going to be plenty big enough
already without saddling it with a major rewrite of the dependency system.
I agree though that it's worth considering defining pg_attribute.attnum as
the logical column position so as to minimize the effects on client-side
code. I doubt there is much stuff client-side that cares about column
creation order, but there is plenty that cares about logical column order.
OTOH this would introduce confusion into the backend code, since Alvaro's
definition of attnum is what most of the backend should care about.
regards, tom lane
