On ons, 2010-05-12 at 12:44 +0100, Greg Stark wrote:
> Well you could imagine doing this for all our types by doing:
>
> search and replace int4 -> pgint4 etc.
> add #ifndef int4 #define int4 pgint4 at the end of postgres.h
>
> That way third-party apps which define their own int4 would be
> required to use pgint4. But third-party apps which don't could
> continue to use int4. All struct interfaces etc would be defined using
> pgint4 directly so wouldn't be affected by any unusual definition of
> int4.
>
> The trick would be to ensure that nothing in the postgres interfaces
> depend on the bool or int4 definitions. That would be easy to ensure
> after the search/replace but hard to guarantee long-term.
The problem with the bool type is that it could have different sizes on
different systems. Which will lead to problems. I doubt that that
problem exists with int4.
There is the somewhat related issue that we should be using int32
instead of int4 (and indeed most of our header files do, but not all),
and if we wanted to ever change anything about that, we should probably
go with int32_t. But in none of these cases is there any chance of a
binary representation mismatch. (Except perhaps int8. :-) )