Tom Lane wrote:

Andreas Pflug <[EMAIL PROTECTED]> writes:


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.



That's exactly the same thing I am saying. Your mistake is to assume
that this function can be combined with identification of a (changeable)
logical column position. It can't. Changeability and immutability are
just not compatible requirements.


In the mind of a programmer, a ALTER COLUMN doesn't create a new column, but merely changes some attributes of an existing column. In this sense, changeability and immutability are not controversal.

Digging deeper:

TupDesc contains an array of physical attr descriptions, and to access a column description attnum is taken as index into that array (taken from fastgetattr).

return fetchatt(tupleDesc->attrs[attnum-1], ...)

The physical location can easily reordered if there's an additional array, to translate attnum into the array index.

return fetchatt(tupleDesc->attrs[tupleDesc->attrpos[attnum-1]] ...

For sure, reordering (i.e. changing the attrpos array) may only be performed as long as the column isn't referenced.

Regards,
Andreas



---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
     subscribe-nomail command to [EMAIL PROTECTED] so that your
     message can get through to the mailing list cleanly

Reply via email to