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.

If we fail on load, we should fail on dump. Why not fail on COPY WITH
OIDS on a non-oid table?

> >> 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

We have a script to detect them and the oid counter it unique. In what
way do we not enforce it.

> 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.

Interesting idea.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026