Andreas Pflug <[EMAIL PROTECTED]> 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. 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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])