Andreas Pflug <[EMAIL PROTECTED]> writes: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.
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.
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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
