From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Curt Sampson <cjs(at)cynic(dot)net> |
Cc: | Jules Alberts <jules(dot)alberts(at)arbodienst-limburg(dot)nl>, Postgres Admin List <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Fw: OID |
Date: | 2002-08-19 15:04:01 |
Message-ID: | 7007.1029769441@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Curt Sampson <cjs(at)cynic(dot)net> writes:
> On Mon, 19 Aug 2002, Jules Alberts wrote:
>> Is there any consensus aboit avoiding OIDs? I'm running a small test
>> system right now using OIDs as a means to refer to BLOBs. Should I
>> expect any trouble using OIDs in our future production system?
> I don't know if there's a consensus, but I certainly avoid using OIDs
> completely in my own tables. They're can wrap, for a start, so in a
> really busy, large database you might end up getting one that you
> already have. Also, I don't like "hidden" fields; if I'm going to refer
> to soemething, I like it to be nice and obvious what's being referred
> to. And of course they're not portable.
As far as using BLOBs goes, you don't have a lot of choice: the lo_xxx
family of functions take and return OID, end of story. Of course
Postgres' notion of a BLOB isn't very portable anyway.
I do agree that for a primary key in a user table, there's no very good
reason to use OIDs rather than using a SERIAL field (ie, a sequence).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Zouroudis | 2002-08-19 15:34:54 | need help with an insert statement |
Previous Message | Curt Sampson | 2002-08-19 14:51:20 | Re: Fw: OID |