int8 sequences --- small implementation problem

Jan Wieck <JanWieck@yahoo.com> writes:
>     And he who needs that kind of long term row identifiers would
>     be better off with 8-byte sequences anyway - IMNSVHO.

Indeed.  I've been looking at switching sequences to be int8, and I see
just one little problem, which is to uphold the promise that they'll
still work as if int4 on a machine that has no int64 C datatype.
The difficulty is that sequence.h has

typedef struct FormData_pg_sequence
{NameData    sequence_name;int32        last_value;int32        increment_by;int32        max_value;int32
min_value;int32       cache_value;int32        log_cnt;char        is_cycled;char        is_called;
 
} FormData_pg_sequence;

If I just change "int32" to "int64" here, all is well on machines where
sizeof(int64) is 8.  But if there's no 64-bit C datatype, int64 is
typedef'd as "long int", so sizeof(int64) is only 4.  Result: the struct
declaration won't agree with the heaptuple layout --- since the tuple
routines will believe that the datatype of these columns has size 8.

What I need is a way to pad the struct declaration so that it leaves
8 bytes per int64 column, no matter what.  I thought of

typedef struct FormData_pg_sequence
{NameData    sequence_name;int64        last_value;
#ifdef INT64_IS_BUSTEDint32        pad1;
#endifint64        increment_by;
#ifdef INT64_IS_BUSTEDint32        pad2;
#endifint64        max_value;
#ifdef INT64_IS_BUSTEDint32        pad3;
#endifint64        min_value;
#ifdef INT64_IS_BUSTEDint32        pad4;
#endifint64        cache_value;
#ifdef INT64_IS_BUSTEDint32        pad5;
#endifint64        log_cnt;
#ifdef INT64_IS_BUSTEDint32        pad6;
#endifchar        is_cycled;char        is_called;
} FormData_pg_sequence;

This would work, I think, but my goodness it's an ugly solution.
Has any hacker got a better one?
        regards, tom lane