Re: Re: Notes about int8 sequences

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Roderick A(dot) Anderson" <raanders(at)tincan(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Notes about int8 sequences
Date: 2001-08-06 23:02:19
Message-ID: 26106.997138939@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Roderick A. Anderson" <raanders(at)tincan(dot)org> writes:
> On Mon, 6 Aug 2001, Tom Lane wrote:
>> Hmm. That's a possibility. There's some potential for trouble if an
>> application is expecting an int4 result from "SELECT nextval()" and
>> gets int8 instead, but if we think we could live with that...

> I assume there will be the same limitations as you mentioned in your
> original message. Ie. some systems don't have an 8-byte-int C datatype
> so would still have the 2^31 limit.

Check.

>> Actually, if we thought we could live with that, my inclination would be
>> to blow off int4-based sequences altogether, and just redefine SEQUENCE
>> objects as operating on INT8. Interesting thought, eh?

> More than interesting ... excellant. Bigger is better, right?

Until it breaks your app, yes ;-)

One thing that would have to be thought about is whether the SERIAL
pseudo-type should generate an int8 instead of int4 column. On
compatibility grounds, it might be better to leave it generating int4,
and invent a second pseudo-type SERIAL8 that is just the same except
for making an int8 column. I'm more worried about changing the datatype
of a user column than I am about changing the output type of nextval(),
so I'd be sort of inclined to have two SERIAL types even if we change
nextval() to int8. Thoughts?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris 2001-08-06 23:05:13 Re: user guide
Previous Message Roderick A. Anderson 2001-08-06 22:34:21 Re: Re: Notes about int8 sequences