On Tue, Jul 6, 2010 at 2:49 PM, Alvaro Herrera <alvhe...@commandprompt.com> wrote: > Excerpts from Robert Haas's message of mar jul 06 10:08:21 -0400 2010: > >> Treating OID as a user-defined column seems reasonable, and probably >> not even that messy if we put some appropriate macros in place. I'm >> guessing the messy part would be finding all the places that expect to >> be consulting a real pg_attribute row and supplying them with a >> faked-up one in its place. > > Agreed. > > I'm intending to work on logical column identifiers for 9.1. Perhaps I > could try to have a look at this, too, while at it.
I have a strong suspicion that's going to be a, ahem, challenging project. But it would be great to have. Getting rid of the system column entries from pg_attribute is probably easy by comparison. When we discussed this previously, Tom suggested that we might want to have a three-tiered structure: (1) permanent identifier (never changes, used by other system catalogs to reference the attribute in question), (2) display position, and (3) physical storage position. I'm not sure if it's feasible to think about splitting out (2) and (3) in a single patch, but either one would be useful by itself. Which are you planning to work on? One other thought for you to mull over. Currently, we can never really totally get rid of an attribute because it would leave us at a loss as to how to interpret the tuples already on disk - we can't cope with HeapTupleHeaderGetNatts ever decreasing. But maybe instead of storing natts in the tuple header, we could store a "tuple version number". Whenever a column is added or dropped, physical storage layout is changed, etc., we bump the tuple version number but retain the information necessary to interpret old tuple versions. After CLUSTER or VACUUM FULL, we can forget about all the old tuple versions. A regular VACUUM can, if it visits the entire table, forget about all tuple versions other than the latest which are observed not to be in use. It's a bit awkward if you go to make a change and discover that all 2047 possible tuple versions are in use, because now you have to force a table rewrite for an operation that doesn't normally require one. But in the immortal words of Bill Gates, 640K ought to be enough for anybody. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers