Re: unique row identifier data type exhausted . . .

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Andrew Snow <als(at)fl(dot)net(dot)au>
Cc: "Pgsql-General(at)Postgresql(dot) Org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: unique row identifier data type exhausted . . .
Date: 2000-04-23 11:22:04
Message-ID: 200004231122.HAA23238@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

>
> > It feels like there should be some *really* obvious answer to this
> > question, and I'll find myself whacking my forehead in self-abasement
> > and out of sheer relief to have found the answer to a problem that
> > should not have bothered me in the first place since the answer is too
> > self-evident . . . however, it is bothering me: what happens if the data
> > type that you've chosen to uniquely identify a row is exhausted? If, for
> > instance you use int4 and you've had your couple billion deletes and
> > inserts on the table and the next nextval('seq') . . . well, what
> > exactly happens and how do they do it? Admittedly, 10^9 is a big number
> > but it is far from out of the question that you'd reach it on a really
> > busy database (can't think of a real-world example but that ought to be
> > a moot point), not to mention oids since they are unique across an
> > entire database.
>
> I am curious to know how difficult it would be (if at all) to change the
> type that oid represents, to a 64 bit number. C'mon guys, this isn't the 90s
> any more!

When we are sure all platforms support 64-bit int's, we will move in
that direction.

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Juhan Ernits 2000-04-23 12:03:27 recreate system indexes in 6.5?
Previous Message Andrew Schmeder 2000-04-23 04:43:03 Large objects...