Re: logical column position

Tom Lane wrote:

>Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
>
>
>>I don't quite understand your argumentation.
>>
>>
>
>My point is that to change attnum into a logical position without
>breaking client apps (which is the ostensible reason for doing it
>that way), we would need to redefine all system catalog entries that
>reference columns by attnum so that they also store logical rather than
>physical position. That has a number of serious problems, one big one
>being the difficulty of updating them all correctly during a column
>renumbering operation. More, it turns what would otherwise be a
>relatively localized patch into a massive and bug-prone backend
>modification.
>
>I think it is better to consider attnum as sort of a mini-OID: any one
>column has a uniquely assigned attnum that will never change and can
>be relied on to identify that column. This is essentially how it is
>being used now (remember attnum is part of the PK for pg_attribute)
>and the fact that it is also the physical position is really rather
>incidental as far as the system catalogs are concerned.
>
>
I agree considering attrelid/attnum as kind-of OID, but a relation's
pg_class.oid won't change at ALTER TABLE either, I'd expect the same
from ALTER COLUMN.

>You're quite right that attnum is serving three purposes, but that
>doesn't mean that we can choose at random which purpose(s) to decouple.
>Abandoning the assumption that attnum is a permanent identifier would
>break a lot of things --- probably not only in the backend, either.
>
>

Maybe my proposal wasn't clear enough:
Just as an index references a pg_class entry by it's OID, not some value
identifying it's physical storage, all objects might continue
referencing columns by attnum. Only tuple handling functions like
heap_getattr and heap_formtuple need to know how to extract a Datum by
its attnum from a HeapTuple or how to compile a HeapTuple correctly. If
reshuffling columns is done inside of these functions, it would be
transparent to the rest of the backend and the clients. Hopefully, there
are not too much of such functions, or fancy modules bypassing them...

Regards,
Andreas