Hannu Krosing <hannu@tm.ee> writes:
> Tom Lane wrote:
>> Based on the discussion so far, here is an attempt to flesh out the
>> details of what to do with OIDs for 7.2:
> Also OIDS should be promoted to 8-byte integers at some future time.
Perhaps, but I'm trying to focus on what to do for 7.2...
>> 9. To continue to support COMMENT ON COLUMN when columns have no OIDs,
>> pg_description will be modified so that its primary key is (object type,
>> object OID, column number) --- this also solves the problem that comments
>> break if there are duplicate OIDs in different system tables.
> Hm.. To me this sounds like allowing duplicates in an unique index in
> case there happen to be duplicate keys there ;)
Unless you want to implement a global unique index that can enforce
uniqueness of OIDs across all the system tables, I don't think that
approach is tenable. pg_description is broken as it stands. Bruce
doesn't like the "column number" part of my proposal --- I suppose he'd
rather see the pg_description key as just <object type, object OID> with
object type referring to pg_attribute if it's a comment on column.
That would work too as far as fixing the lack of uniqueness goes, but it
still leaves us with pg_attribute as a significant consumer of OIDs.
Since the major point of this exercise (in my mind) is cutting the rate
of consumption of OIDs to postpone wraparound, I want to suppress OIDs
in pg_attribute, and to do that I have to add the column number to
pg_description.
>> The column number field will be zero for all object types except columns.
>> For a column comment, the object type and OID fields will refer to the
>> parent table, and column number will be nonzero.
> What happens to columns added to inherited tables ?
Uh, nothing as far as I can see. We don't presently support auto
inheritance of comments-on-columns, if that's what you were asking for.
Offhand, making that happen seems about equally easy with either
representation of pg_description, so I don't think it's an issue.
regards, tom lane