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(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