RE: PATCH: Postgresql Patch

See doc on OID from
http://www.postgresql.org/docs/8.3/static/datatype-oid.html

The oid type is currently implemented as an unsigned four-byte integer.
Therefore, it is not large enough to provide database-wide uniqueness in
large databases, or even in large individual tables. So, using a
user-created table's OID column as a primary key is discouraged. OIDs are
best used only for references to system tables.

-----Original Message-----
From: Guillaume Cottenceau [mailto:[email protected]] 
Sent: 23 June 2008 06:12 PM
To: Hillel
Cc: [email protected]
Subject: Re: PATCH: Postgresql Patch

"Hillel" <hillel 'at' ecommunicate.biz> writes:

> Hi,
>
> If the table has bar, baz set as the primary key it will only delete once.
> In our case you should make smsc,ts the primary key. This also then has
the

This is not an option - my message implied that there can be
multiple rows with a unique combination of smsc,ts.


[...]

> Another option is to use a serial column as it works well as shown below
and
> then we have replaced the previous Automatic OIDs with a sequential id.

As far as I can tell, that's what you denied doing in:

http://www.kannel.org/pipermail/devel/2008-June/001764.html

(although it seems to me that it doesn't relate to the
configuration).

It seems that it is also the opinion of Stipe, although I cannot
be sure:

http://www.kannel.org/pipermail/devel/2008-June/001767.html

although that's the cleanest solution, in my humble opinion -
other than creating tables WITH OIDS as I suggested here:

http://www.kannel.org/pipermail/devel/2008-June/001770.html

which no one answered, by the way.


At that point in the discussion, I find my patch with 'ctid' to
be a better solution, if WITH OIDS and using a SERIAL column are
ruled out. It's the closest implementation to the current one
using oid's.


> OIDs are a scarce resource, and if you run low on them it all goes
horribly
> wrong as OIDs are used for all sorts of stuff internal to the database, so
> if you use them all up on user tables it can cause problems.

Do you have pointers to support that claim? I can find none on
pg's site.

-- 
Guillaume Cottenceau, MNC Mobile News Channel SA, an Alcatel-Lucent Company
Av. de la Gare 10, 1003 Lausanne, Switzerland - direct +41 21 317 50 36