From: | Alke <alke(at)iol(dot)it> |
---|---|
To: | pgsql-general(at)hub(dot)org |
Cc: | Jay Bloodworth <jay(at)dokodiner(dot)com> |
Subject: | Re: SERIAL vs. OIDs |
Date: | 1999-08-30 13:56:23 |
Message-ID: | 37CA8D87.7E5E464B@iol.it |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
OIDs Cons:
* The code executend in triggers (written in plpgsql) can't know the OID
of the inserted/updated/deleted row.
This problem make me pass from OIDs to SERIALs, 'cause I need to know an
identifier of the row in order to make referential integrity...and I wasn't able
to obtain that with OIDs.
If someone know a work-around to this problem, please let me know...
Paolo Salvn
> Date: Sun, 29 Aug 1999 22:52:11 +0000
> From: Jay Bloodworth <jay(at)dokodiner(dot)com>
> Subject: SERIAL vs. OIDs
>
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Hub.Org News Admin | 1999-08-30 15:13:27 | |
Previous Message | José Soares | 1999-08-30 13:19:25 | Re: [HACKERS] getting at the actual int4 value of an abstime |