Re: OID wraparound: summary and proposal

> Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026