Re: Status of OIDs was: Re: select first occurrence of a table

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Benjamin Scherrey <scherrey(at)proteus-tech(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Status of OIDs was: Re: select first occurrence of a table
Date: 2003-05-04 23:06:11
Message-ID: 20030504230611.GM2619@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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)

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Kevin Murphy 2003-05-05 00:32:33 input buffer overflow, can't enlarge buffer because scanner uses REJECT
Previous Message Arguile 2003-05-04 21:03:41 Re: Changing date style output format