RE: unique row identifier data type exhausted . . .

For me it seems more a design problem than the length of internal number....

Why not create a table with 2 field containing int, setting the primary key
on both of them and running a sequencing scheme on both as if it was a
single number....

There are no more limitations anymore, as if you know you will need a lot of
record you may decide to use 1, 2, or 3 numbers...

Question, does postgress is able to run sequence on 2 combined numbers...

Cheers...

Franck Martin
Network and Database Development Officer
SOPAC South Pacific Applied Geoscience Commission
Fiji
E-mail: franck(at)sopac(dot)org(dot)fj <mailto:franck(at)sopac(dot)org(dot)fj>
Web site: www.sopac.org.fj <http://www.sopac.org.fj>

-----Original Message-----
From: Tom Cook [mailto:tcook(at)lisa(dot)com(dot)au]
Sent: Wednesday, April 26, 2000 11:49 AM
To: Pgsql-General(at)Postgresql(dot) Org
Subject: RE: [GENERAL] unique row identifier data
type exhausted . . .

On Mon, 24 Apr 2000, Andrew Snow wrote:

> > When we are sure all platforms support 64-bit int's, we
will move in
> > that direction.
>
> Sorry if this is a stupid question, but couldn't you
fairly easily make it
> an option at compile time? To use either 32 or 64 bit
OID's.
> (And, less importantly, for sequences)

Is this necessarily a good solution? If you use 64-bit OIDs,
some joker
will just hook up a several-terra-byte disk array to his
machine, try to
store the location of every molecule in the universe and
break it.

Admittedly, ~2x10^20 is a very large number, but that's what
they thought
about 2000, also...

What I'm saying is, is there a better way of doing this?