Re: OID wraparound: summary and proposal - Mailing list pgsql-hackers

> Given Hiroshi's objections, and the likelihood of compatibility problems
> for existing applications, I am now thinking that it's not a good idea to
> turn off OID generation by default.  (At least not for 7.2 --- maybe in
> some future release we could change the default.)

This seems good.  People with oid concerns usually have 1-2 huge tables
and the rest are small.

> Based on the discussion so far, here is an attempt to flesh out the
> details of what to do with OIDs for 7.2:
> 
> 1. Add an optional clause "WITH OIDS" or "WITHOUT OIDS" to CREATE TABLE.
> The default behavior will be WITH OIDS.

Makes sense.

> Note: there was some discussion of a GUC variable to control the default.
> I'm leaning against this, mainly because having one would mean that
> pg_dump *must* write WITH OIDS or WITHOUT OIDS in every CREATE TABLE;
> else it couldn't be sure that the database schema would be correctly
> reconstructed.  That would create dump-script portability problems and
> negate some of the point of having a GUC variable in the first place.
> So I'm thinking a fixed default is better.

Good point.

> Note: an alternative syntax possibility is to make it look like the "with"
> option clauses for functions and indexes: "WITH (oids)" or "WITH (noOids)".
> This is uglier today, but would start to look more attractive if we invent
> additional CREATE TABLE options in the future --- there'd be a place to
> put 'em.  Comments?

I don't like the parens.  Looks ugly and I am not used to seeing them
used that way.  I can imagine later using WITH NOOIDS, NOBIBBLE, BABBLE.
Maybe the syntax should be WITH OID, WITH NOOID?


> 2. A child table will be forced to have OIDs if any of its parents do,
> even if WITHOUT OIDS is specified in the child's CREATE command.  This is
> on the theory that the OID ought to act like an inherited column.

Good point.

> 3. For a table without OIDs, no entry will be made in pg_attribute for
> the OID column, so an attempt to reference the OID column will draw a
> "no such column" error.  (An alternative is to allow OID to read as nulls,
> but it seemed that people preferred the error to be raised.)

Makes sense.

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

> 7. Physical tuple headers won't change.  If no OIDs are assigned for a
> particular table, the OID field in the header will be left zero.
> 
> 8. OID generation will be disabled for those system tables that don't need
> it --- pg_listener, pg_largeobject, and pg_attribute being some major
> offenders that consume lots of OIDs.
> 
> 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.  I still prefer pg_attribute to have oids.  Can we
have temp tables have no pg_attribute oids?  A hack on a hack?

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