Re: Re: Notes about int8 sequences
От | Tom Lane |
---|---|
Тема | Re: Re: Notes about int8 sequences |
Дата | |
Msg-id | 26106.997138939@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: Notes about int8 sequences ("Roderick A. Anderson" <raanders@tincan.org>) |
Ответы |
Re: Re: Notes about int8 sequences
|
Список | pgsql-hackers |
"Roderick A. Anderson" <raanders@tincan.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
В списке pgsql-hackers по дате отправления: