Re: int8 sequences --- small implementation problem

Поиск
Список
Период
Сортировка
От Serguei Mokhov
Тема Re: int8 sequences --- small implementation problem
Дата
Msg-id 00ff01c124db$b9cc5b60$5dd9fea9@gunn
обсуждение исходный текст
Ответ на Re: Surviving transaction-ID wraparound, take 2  (Jan Wieck <JanWieck@Yahoo.com>)
Список pgsql-hackers
----- Original Message ----- 
From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Tuesday, August 14, 2001 11:28 AM


> "Serguei Mokhov" <sa_mokho@alcor.concordia.ca> writes:
> >> This would work, I think, but my goodness it's an ugly solution.
> 
> > Is anything wrong with just having two int32 per value for this case?
> 
> Well, we do want it to be int64 on machines where int64 is properly
> defined.  Or are you suggesting
> 
> #ifdef INT64_IS_BUSTED
> int32 last_value;
> int32 pad1;
> #else
> int64 last_value;
> #endif
> 
> That does seem marginally more robust, now that you mention it...

Yes, this version is more robust, but you till have to cope with all
those #ifdef INT64_IS_BUSTED #else #endif. I guess if you want explicitly
int64 type in here for those platforms that do support it, then there is no
other way maybe. What I was thinking (for this particular struct only!) is just jave padded
int32's for every value, which will always be correct and no marginal problems.
And the accessor functions using the struct just employ int64 whatever it means.

S.






В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: OID unsigned long long
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Help with Vacuum Failure