Re: Re: OID wraparound: summary and proposal
От | Tom Lane |
---|---|
Тема | Re: Re: OID wraparound: summary and proposal |
Дата | |
Msg-id | 14741.996795477@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: OID wraparound: summary and proposal (Hannu Krosing <hannu@tm.ee>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: