Re: deprecating the use of OIDs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: deprecating the use of OIDs
Date
Msg-id 11439.1064875032@sss.pgh.pa.us
Whole thread Raw
In response to deprecating the use of OIDs  (Neil Conway <neilc@samurai.com>)
Responses Re: deprecating the use of OIDs  (Neil Conway <neilc@samurai.com>)
Re: deprecating the use of OIDs  (Rod Taylor <rbt@rbt.ca>)
List pgsql-hackers
Neil Conway <neilc@samurai.com> writes:
> (1) Add a GUC var, with a name such as "default_use_oids", defaulting to
> true. This controls whether a CREATE TABLE that doesn't include WITH or
> WITHOUT OIDS gets created with OIDs.

This I think was pretty noncontroversial.

> (2) When dumping a table, spit out a "SET default_use_oids = xxx" before
> the CREATE TABLE. This means that if a table was previously created WITH
> OIDS (either explicitly or by default), it will continue to have OIDs
> when the dump is restored (regardless of the default value of the GUC
> var). We could specify WITH or WITHOUT OIDS as part of the CREATE TABLE
> itself, but there were objections earlier about maintaining the
> cleanliness of the SQL produced by pg_dump:

It doesn't seem to me that this really buys much.  What we really want
is a way for a dump/reload to remove OIDs from tables that formerly had
them; otherwise people will not easily be able to migrate their existing
tables away from having OIDs.

> ... and a single SET can apply to
> multiple CREATE TABLEs.

Not unless you want partial pg_restores to break.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 7.4 status
Next
From: Neil Conway
Date:
Subject: Re: deprecating the use of OIDs