Re: OID wraparound: summary and proposal
От | Tom Lane |
---|---|
Тема | Re: OID wraparound: summary and proposal |
Дата | |
Msg-id | 16522.996703774@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: OID wraparound: summary and proposal (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: OID wraparound: summary and proposal
|
Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes: >> For input, I see no downside to just >> ignoring the incoming OIDs. For output, I can see three reasonable >> possibilities: >> >> A. Pretend WITH OIDS wasn't mentioned. This might seem to be >> "do the right thing", but a rather strong objection is that the >> app will not get back the data it was expecting. >> >> B. Return NULLs or 0s for the OIDs column. >> >> C. Raise an error and refuse to do the copy at all. >> >> C is probably the most conservative answer. > If we fail on load, we should fail on dump. Why not fail on COPY WITH > OIDS on a non-oid table? I'm confused --- I was proposing that we *not* fail on load. What's the point of failing on load? >> How so? pg_description is broken anyway given that we don't enforce OID >> uniqueness across system catalogs. Also, in the future we could > We have a script to detect them and the oid counter it unique. In what > way do we not enforce it. In a running system, once the OID counter wraps around there's no guarantee that you won't have duplicate OIDs in different system tables. The only enforcement mechanism we have is the unique indexes, and those will only check per-table. However, that's fine --- it's as much as we need. For everything except pg_description, that is. Since pg_description currently makes an unchecked and uncheckable assumption of global uniqueness of OIDs, it's broken. regards, tom lane
В списке pgsql-hackers по дате отправления: