Skip site navigation (1) Skip section navigation (2)

Re: pgsql oid question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Reggie Burnett" <rykr(at)bellsouth(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgsql oid question
Date: 2003-01-05 06:42:16
Message-ID: 7020.1041748936@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Reggie Burnett" <rykr(at)bellsouth(dot)net> writes:
> I have started experimenting with an access layer for pgsql and have a
> question.  I had someone on this list tell me that the oid values that
> come back from the server are tag identifiers for that row/column
> combination and are not type indicators.

I think your someone is confused. There are no identifiers associated
with row/column combinations.

> Yet, when I create multiple
> tables/columns each having the same type (int32), the same oid keeps
> being returned.

The OIDs returned in RowDescription messages uniquely identify datatypes
(more specifically, pg_type rows).  They will be stable short of DROP
TYPE/CREATE TYPE shenanigans.  (However, user-defined types might not
get the same OIDs assigned after a dump/reload cycle.  It's probably
reasonable to treat type OIDs as stable for the life of a connection,
but not as constants of nature.)

OIDs are also used for other purposes, so your confusion may stem from
confusing pg_type OIDs with other OIDs.  In the current system
implementation, OIDs are unique row identifiers only within individual
tables --- perhaps not even then, if the table doesn't have a unique
index on its OID field.  Thus, a pg_type OID uniquely identifies a
datatype, but that doesn't mean that the same OID number could not
appear in pg_class, pg_rewrite, or other system or user tables.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Reggie BurnettDate: 2003-01-05 07:39:11
Subject: Re: pgsql oid question
Previous:From: Reggie BurnettDate: 2003-01-05 06:23:18
Subject: pgsql oid question

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group