Re: int8 sequences --- small implementation problem

From: "Serguei Mokhov" <sa_mokho(at)alcor(dot)concordia(dot)ca>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jan Wieck" <JanWieck(at)yahoo(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: int8 sequences --- small implementation problem
Date: 2001-08-14 16:10:59
Message-ID: 00ff01c124db$b9cc5b60$5dd9fea9@gunn
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


----- Original Message -----
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Sent: Tuesday, August 14, 2001 11:28 AM

> "Serguei Mokhov" <sa_mokho(at)alcor(dot)concordia(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Padgett 2001-08-14 17:12:26 Re: int8 sequences --- small implementation problem
Previous Message Bruce Momjian 2001-08-14 16:01:11 Re: Re: Use int8 for int4/int2 aggregate accumulators?