Re: OID wraparound: summary and proposal

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> 6. COPY out WITH OIDS will ignore the "WITH OIDS" specification if the
>> table has no OIDs. (Alternative possibility: raise an error --- is that
>> better?) COPY in WITH OIDS will silently drop the incoming OID values.

> Obviously, the case here is that COPY WITH OIDS alone on a non-oid table
> should throw an error, while pg_dump -o should work on a database with
> mixed oid/non-oid. I think the right thing would be to have pg_dump
> check pg_class.relhasoids and issue a proper COPY statement to match the
> existing table.

pg_dump clearly will need to do that, so it isn't really going to be the
issue. The question is what to do when a less-clueful app issues a COPY
WITH OIDS on an OID-less table. 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.

>> 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. The object
>> type is the OID of the system catalog in which the object OID appears.
>> 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.

> Sounds like a hack.

How so? pg_description is broken anyway given that we don't enforce OID
uniqueness across system catalogs. Also, in the future we could
consider overloading the <column number> column to have meanings for
other object types. I could imagine using it to attach documentation to
each of the input arguments of a function, for example.

regards, tom lane