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  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Possible solution for LIKE optimization
Следующее
От: Hiroshi Inoue
Дата:
Сообщение: Re: Possible solution for LIKE optimization