Re: unique row identifier data type exhausted . . .

>
>
> > 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.
>
> If you have to have OIDs at all, its a lot better than a 32 bit number.  I
> think it would be easier to switch to 64 bit OIDs than ditch them
> completely.
> The "serial" type should definitely be 64 bit.  To make matters worse I
> believe its really only a 31 bit number as the plus/minus symbol is
> discarded.  But I think moving to 64 bit will take place soon enough, when
> it needs to, and it should shut everyone up.

If you look at that TODO list, oid's flowing over 32-bits is not
something we are losing sleep over.  In fact, the first fix would be to
make sure oid's are truly treated as unsigned int's, thereby doubling
their range.  I have done some of those myself, but I am sure there are
more areas that need fixing.

Illustra's solution was to use two int32's, making the upper 32-bit
value represent the site, so oid's remain unique as they move between
sites.  If we picked a random 32-bit oid on initdb startup, that would
pretty much make them unique all the time.

>
> > "Christ died for sin, the righteous for the unrighteous, to bring
> > you to God."
> >     - 1 Peter 3:18
>
> Is it just me, or are there a lot of Christian PostgreSQL users? ;-)  (I'm
> not knocking it, I'm one too..)

Good question.  :-)

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