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 по дате отправления: