Thread: OIDS and its limitations

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

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

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