Thread: To OID or not to OID
I've been looking through the archives for guidance on whether or not we should create our tables WITHOUT OIDS. I've seen some discussions about making WITHOUT the default for user tables, and seen some caveats about the oid int value wrapping, etc., but I haven't been able to find a discussion of the relative merits (I'm sure there's been one....) Is there any concrete reason NOT to create tables WITHOUT OIDS? We are going to have some very large tables in our app, so saving the space and not worrying about int-wrap seems like a good idea, but I'm worried that I'm missing something. - DAP ====================================================== David Parker Tazz Networks (401) 709-5130
"David Parker" <dparker@tazznetworks.com> writes: > Is there any concrete reason NOT to create tables WITHOUT OIDS? We are > going to have some very large tables in our app, so saving the space and > not worrying about int-wrap seems like a good idea, but I'm worried that > I'm missing something. Nothing in PG depends on user tables having an OID column. They used to be a way to get a primary key before SERIAL came along, but they are now deprecated for user tables. WITHOUT OIDS will be the default in a future release. -Doug -- Let us cross over the river, and rest under the shade of the trees. --T. J. Jackson, 1863
On Wed, 2004-09-29 at 00:23, Doug McNaught wrote: > Nothing in PG depends on user tables having an OID column. They used > to be a way to get a primary key before SERIAL came along, but they > are now deprecated for user tables. WITHOUT OIDS will be the default > in a future release. Indeed, that will be the default in 8.1, if we stick to the previous discussions on -hackers. 8.0 introduces a GUC variable "default_with_oids" that controls whether OIDs are added to tables by default. In 8.0 this will be true by default (so 8.0 will behave exactly the same as earlier releases), but I'll be pushing for it to be set to false for 8.1. -Neil