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