I think most people on this list will agree that having OIDs on user
tables is a Bad Thing. For some previous discussion of why, see:

http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg27374.html

My understanding of the conclusion of previous discussions on this topic
is that getting rid of OIDs on user tables eventually would be good, but
there is some disagreement / confusion on how exactly to manage the
transition. I think we should do the following for 7.5:

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

(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: if the OID-ness of the table
is specified via a separate statement, it is easier for people porting
the SQL to another DBMS to workaround, and a single SET can apply to
multiple CREATE TABLEs.

(2a) We could also add pg_dump options to control this behavior, if
people like.

(3) Add a comment in the release notes saying: (a) the use of OIDs for
user tables is considered a deprecated feature (b) for compatibility
with future versions of PostgreSQL, admins can try setting the GUC var
to false, so they know which (if any) of their apps actually depend upon
the use of OIDS.

(4) In some future release of PostgreSQL (say, 7.6), toggle the GUC var
to false by default.

Objections, comments, etc. are welcome.

-Neil

P.S. It would be nice if we could get this done by 7.4, so as not to
miss a whole release cycle, but that seems out of the question,
unfortunately.


Mon, 29 Sep 2003 17:27:59 -0400
Neil Conway <neilc@samurai.com>
deprecating the use of OIDs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> I think most people on this list will agree that having OIDs on user
> tables is a Bad Thing. For some previous discussion of why, see:
> ...
> Objections, comments, etc. are welcome.

The GUC route sounds good. I'd like to see ctid handling beefed up at the 
same time. For example, some operators such as != would be nice and might 
ease the pain a little for people used to using oids as their "tuple id" :)

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200309291818

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iD8DBQE/eK/lvJuQZxSWSsgRAtvWAKDViOL/pohprP0ocQilFirfoCgvHwCg3Vrm
zD8P1atONRt2XtGutbToSh0=
=RX5j
-----END PGP SIGNATURE-----



Mon, 29 Sep 2003 22:18:01 -0000
greg@turnstep.com
Re: deprecating the use of OIDs
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

Mon, 29 Sep 2003 18:37:12 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: deprecating the use of OIDs 
On Mon, 2003-09-29 at 18:37, Tom Lane wrote:
> 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.

Can't they just use ALTER TABLE ... WITHOUT OIDS?

> > ... and a single SET can apply to
> > multiple CREATE TABLEs.
> 
> Not unless you want partial pg_restores to break.

So is it worth doing this rather than WITH/WITHOUT OIDS, then?

-Neil



Mon, 29 Sep 2003 18:41:42 -0400
Neil Conway <neilc@samurai.com>
Re: deprecating the use of OIDs
On Mon, 2003-09-29 at 18:18, greg@turnstep.com wrote:
> The GUC route sounds good. I'd like to see ctid handling beefed up at the 
> same time. For example, some operators such as != would be nice and might 
> ease the pain a little for people used to using oids as their "tuple id" :)

Are we encouraging the use of ctids by applications?

-Neil



Mon, 29 Sep 2003 19:00:38 -0400
Neil Conway <neilc@samurai.com>
Re: deprecating the use of OIDs
> 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.

Doesn't ALTER TABLE ... SET WITHOUT OIDS allow that?
Mon, 29 Sep 2003 19:18:29 -0400
Rod Taylor <rbt@rbt.ca>
Re: deprecating the use of OIDs
Neil Conway <neilc@samurai.com> writes:
> On Mon, 2003-09-29 at 18:37, Tom Lane wrote:
>> 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.

> Can't they just use ALTER TABLE ... WITHOUT OIDS?

That's true --- I'd forgotten we had that.

>>> ... and a single SET can apply to
>>> multiple CREATE TABLEs.
>> 
>> Not unless you want partial pg_restores to break.

> So is it worth doing this rather than WITH/WITHOUT OIDS, then?

[shrug]  It seems quite cosmetic to me.  What might be more useful is
an option to keep pg_dump from saying either WITH OIDS or WITHOUT OIDS,
probably as part of a more general "suppress Postgres-isms" option.

			regards, tom lane

Mon, 29 Sep 2003 19:45:19 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: deprecating the use of OIDs 
Neil Conway <neilc@samurai.com> writes:
> On Mon, 2003-09-29 at 18:18, greg@turnstep.com wrote:
>> The GUC route sounds good. I'd like to see ctid handling beefed up at the 
>> same time. For example, some operators such as != would be nice and might 
>> ease the pain a little for people used to using oids as their "tuple id" :)

> Are we encouraging the use of ctids by applications?

I'd prefer to think not ... but they are a nice "out" in some situations.
I suppose we could at least document them a little better.

			regards, tom lane

Mon, 29 Sep 2003 19:50:35 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: deprecating the use of OIDs 