The other disadvantage of oids is that since Postgres doesn't currently
support
DELETE COLUMN, if you want to use the work around of doing a SELECT INTO
another
table it doesn't work because the oids are changed. In general, until
Postgres supports a fuller range of schema change functions you will
find
certain things like this inconvenient. Of course even the above has
another
work around. Either way can be made to work fine. I actually prefer
OIDS, but
I would suggest you use serials. I swapped over from oids to serials and
I'm
in two minds whether I'm better off.
Jay Bloodworth wrote:
>
> Seeking informed opinion on what is better to use as a unique row id for
> linking tables together in a normalized database, a SERIAL field or the
> pgsql OID. This is for an intranet application with a small user base,
> but I'd like to make it robust and scalable where it is easy to do so.
> My conclusions so far:
>
> OIDs:
>
> Pros:
> * They're already there; save a couple bytes per row
> * Specific method to retrieve after INSERT (maybe faster than SELECT
> on the sequence)
>
> Cons:
> * Not serial by table; hard to build linked table 'by hand'
> * not pure SQL
>
> SERIAL:
>
> Pros:
> * Based on fairly vanilla SQL
> * Easier to reproduce all or part of a db on a dump/restore
>
> Cons:
> * Performance?
> * Extra id field redundant
>
> I'm sure I'm missing something, and I'm not entirely sure how to weight
> the points I've got. Advice appreciated.
>
> Please CC me. I subscribed to the digest.
>
> Jay
>
> ************