Jan Wieck <[EMAIL PROTECTED]> 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_BUSTED
int32 pad1;
#endif
int64 increment_by;
#ifdef INT64_IS_BUSTED
int32 pad2;
#endif
int64 max_value;
#ifdef INT64_IS_BUSTED
int32 pad3;
#endif
int64 min_value;
#ifdef INT64_IS_BUSTED
int32 pad4;
#endif
int64 cache_value;
#ifdef INT64_IS_BUSTED
int32 pad5;
#endif
int64 log_cnt;
#ifdef INT64_IS_BUSTED
int32 pad6;
#endif
char 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
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
