http://www.postgresql.org/docs/faqs.FAQ.html#item4.12
Basically, the OID can be dangerous to use if you have a very busy database because it can be a timebomb. Even if your database cleans out old records and creates new ones, that OID is still growing and is still used as one serial ID across several tables. Eventually that OID will run out of space and will start all over again. Sure, it takes 4 billion rows for that to happen, but take for instance a job search site where records are added and deleted constantly. Eventually within like 5 or 6 years, with enough load, you just might hit 4 billion rows created, even though your database size might only be like 2GB at a given moment in time.4.12) What is an OID? What is a CTID?
If a table is created WITH OIDS, each row gets a unique a OID. OIDs are automatically assigned unique 4-byte integers that are unique across the entire installation. However, they overflow at 4 billion, and then the OIDs start being duplicated. PostgreSQL uses OIDs to link its internal system tables together.
To uniquely number rows in user tables, it is best to use SERIAL rather than OIDs because SERIAL sequences are unique only within a single table. and are therefore less likely to overflow. SERIAL8 is available for storing eight-byte sequence values.
CTIDs are used to identify specific physical rows with block and offset values. CTIDs change after rows are modified or reloaded. They are used by index entries to point to physical rows.
So, if you were using your OID mechanism as, say, a way for your admin pages to allow you to edit a record from a grid click, you would eventually be up the creek and get an error.
In other words, OIDs cannot be trusted and should not be used. If you really want to trust a way to have a grid click to edit a single record, you must key it some how. Therefore, add a SERIAL8 column to your table. That way, you guarantee uniqueness to that table and to that row.