> Bruce Momjian <[EMAIL PROTECTED]> 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
  [EMAIL PROTECTED]               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to