Re: heap_create with OID?

Philip Warner <pjw@rhyme.com.au> writes:
> This might work...the idea would presumably be to load the BLOBs before the
> schema, since the OIDs of the BLOBS might be low, and hence conflict could
> occur if many tables were defined after the first blob was loaded in the
> original DB.

> 1. createdb
> 2. load all blobs
> 3. Do remaining restore steps

If you're reloading everything in OID order, then blobs need no special
ordering treatment ;-)

> The only real problem (and this is in pg_dump as well), is if a table is
> dumped with OIDs and the OIDs conflict with automatically generated ones
> for the schema. Although this may not be an issue: how unique are OIDs,
> anyway? Will corruption of any kind occur in the above case (even with the
> old pg_dump)?

In theory OIDs are unique (within one database anyway).  There are a
couple of ways that theory can fail:

1. User-supplied OIDs (via COPY WITH OIDs) might conflict.

2. Run the system long enough, the OID counter will wrap around and  start generating already-used numbers.

The next question is what happens if we do have duplicate OIDs.  AFAIK,
if the duplicate OIDs are for different kinds of entities (eg, rows in
different tables) the answer is "no problem".  Duplicate OIDs for, say,
two tables would be disastrous --- but the unique index on pg_class.oid
should prevent you from creating duplicates.  I *think* that 7.0 has
unique indexes on every system table where it's important to prevent
duplicate OIDs.  (If not, it's an easily corrected omission; anyone want
to run through the tables and double-check?)

OIDs aren't magic, they're just another number.  The system depends on
the assumption that OIDs are unique keys for certain system tables, and
it enforces (or should enforce) this assumption.  Applications might
depend on the assumption that OIDs are unique keys for their own tables;
if so they can and should enforce that assumption with unique indexes.
But there's no hidden mechanism that will make the system go belly-up
just because there are identical OIDs floating around.
        regards, tom lane

PS: I believe the "comment" support will misbehave if there are
duplicate OIDs in different system tables, since it assumes that an OID
is sufficient to identify any database object regardless of type.
But the comment stuff is not exactly mission-critical...