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