Re: Status of OIDs was: Re: select first occurrence of a table - Mailing list pgsql-general

From Alvaro Herrera
Subject Re: Status of OIDs was: Re: select first occurrence of a table
Date
Msg-id 20030504230611.GM2619@dcc.uchile.cl
Whole thread Raw
In response to Status of OIDs was: Re: select first occurrence of a table  (Benjamin Scherrey <scherrey@proteus-tech.com>)
Responses Re: Status of OIDs was: Re: select first occurrence of a table  (Benjamin Scherrey <scherrey@proteus-tech.com>)
List pgsql-general
On Fri, May 02, 2003 at 04:26:27PM -0400, Benjamin Scherrey wrote:
> Speaking of OIDs... I noticed that the talk is that these are being
> deprecated which, from my non relationally purist/pro-object
> perspective, kinda disappointed me although I can guess at some
> possible reasons. Is there some docs or a thread that someone can
> point me to that covers this issue as I expect its been hashed over in
> depth already. I'd appreciate any information about the justification
> and expected impact of this direction that Postgres is taking.

What do you mean by deprecated?  They are not certainly going to
disappear.  But user tables can be created without them, and it's
desirable to do so for a number of reasons.

If you want to have a unique identifier that's a single column and your
table has a multicolumn primary key, use another column tied to a
sequence.  I don't know what other use you can give to an OID column in
a user table, but in this case you have the same overhead (4 bytes, or 8
if you need more space) with less problems, particularly wraparound.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La virtud es el justo medio entre dos defectos" (Aristoteles)


pgsql-general by date:

Previous
From: Arguile
Date:
Subject: Re: Changing date style output format
Next
From: Kevin Murphy
Date:
Subject: input buffer overflow, can't enlarge buffer because scanner uses REJECT