Re: logical column position
От | Andreas Pflug |
---|---|
Тема | Re: logical column position |
Дата | |
Msg-id | 3FBE417F.10109@pse-consulting.de обсуждение исходный текст |
Ответ на | Re: logical column position (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: >Andreas Pflug <pgadmin@pse-consulting.de> 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
В списке pgsql-hackers по дате отправления: