> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I don't see any value in dropping oid from pg_attribute.
>
> Conservation of OIDs. Assigning an OID to every row of pg_attribute
> chews up lots of OIDs, for a table that should never be referenced by
> OID --- its primary key is (table OID, attribute number).
>
> Right now this isn't really significant, but if/when we have an option
> to suppress OID generation for user tables, I have every intention of
> applying it to a bunch of the system tables as well. pg_attribute is
> a prime candidate.
>
> ("When" probably means "next month", btw. This is on my 7.2 list...)
Yikes, I am not sure we are ready to make oids optional. System table
oid's seem like the last place to try and preserve oids. Do we return
unused oids back to the pool on backend exit yet? (I don't see it on
the TODO list.) That seems like a much more profitable place to start.
Will we have cheap 64-bit oids by the time oid wraparound becomes an
issue?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026