Re: logical column position - Mailing list pgsql-hackers

From Andreas Pflug
Subject Re: logical column position
Date
Msg-id 3FBE417F.10109@pse-consulting.de
Whole thread Raw
In response to Re: logical column position  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Anyone working on pg_dump dependency ordering?
Next
From: Josh Berkus
Date:
Subject: Re: [PERFORM] More detail on settings for pgavd?