OIDS and its limitations

[Amir Khawaja]

Hi Everyone,

I have a rather trivial (I hope) question about OID types and
PostgreSQL. Since PostgreSQL creates tables "WITH OIDS" by default, I'm
wondering if it is bad practice to allow the default behaviour. For
example, if I have a database with 60+ tables (all tables have their own
PK that is not of type OID) and all of them have an OID field created by
PostgreSQL by default, will this be problematic in the long run? For
example, if I have 30 tables with records greater than 500,000, will
PostgreSQL choke?

Thank you in advance for any information you can provide!
--
Amir Khawaja.

----------------------------------
Rules are written for those who lack the ability to truly reason, But
for those who can, the rules become nothing more than guidelines, And
live their lives governed not by rules but by reason.
- James McGuigan

[Martijn van Oosterhout]

The OIDs won't hurt except take a little disk space. The only thing is that
if they overflow you run a very small chance one of your DDL statements amy
fail.

This feature has only just become optional and everything worked fine before then.

Hope this helps,

On Fri, Jan 09, 2004 at 04:52:04PM -0800, Amir Khawaja wrote:

Hi Everyone,

I have a rather trivial (I hope) question about OID types and
PostgreSQL. Since PostgreSQL creates tables "WITH OIDS" by default, I'm
wondering if it is bad practice to allow the default behaviour. For
example, if I have a database with 60+ tables (all tables have their own
PK that is not of type OID) and all of them have an OID field created by
PostgreSQL by default, will this be problematic in the long run? For
example, if I have 30 tables with records greater than 500,000, will
PostgreSQL choke?

Thank you in advance for any information you can provide!


--
Amir Khawaja.

----------------------------------
Rules are written for those who lack the ability to truly reason, But
for those who can, the rules become nothing more than guidelines, And
live their lives governed not by rules but by reason.
- James McGuigan

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html
--
Martijn van Oosterhout <kl*****@svana.org> http://svana.org/kleptog/ (... have gone from d-i being barely usable even by its developers
anywhere, to being about 20% done. Sweet. And the last 80% usually takes
20% of the time, too, right?) -- Anthony Towns, debian-devel-announce

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAAaX3Y5Twig3Ge+YRAqCHAKCavXObAiQdvknKQPmb9r XqucSklgCgqiN1
V88GB2FfKgPyYc+Aar1syR8=
=vty6
-----END PGP SIGNATURE-----

[Sai Hertz And Control Systems]

Hi Amir Khawaja ,

I have a rather trivial (I hope) question about OID types and
PostgreSQL. Since PostgreSQL creates tables "WITH OIDS" by default,
I'm wondering if it is bad practice to allow the default behaviour.
For example, if I have a database with 60+ tables (all tables have
their own PK that is not of type OID) and all of them have an OID
field created by PostgreSQL by default, will this be problematic in
the long run? For example, if I have 30 tables with records greater
than 500,000, will PostgreSQL choke?

I have done this in one of my project which was using OID'S (i.e tables
were created with OIDS nothing more) thus data inserted into the table
of a database generated new OID's and it was from this list I came to
know that one of the guys table have exausted all the OIDS and to get
around this problem he had to drop recreate the database and again
populate the tables.
From this point onwards I decided to create Tables WITHOUT OIDS and yes
my aplication is running fine.
This was with PostgreSQL 7.3.x and 7.4.x could not tell about the older one.

Even the documentation (Read Chapter 8 of SQL language-> data type )
Says "So, using a user-created table's OID column as a primary key is
discouraged. OIDs are best used only for references to system tables. "
Hope this helps

Regards
Vishal Kashyap

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly