Tom Lane wrote:
> Paul Caskey <paul(at)nmxs(dot)com> writes:
> > But first, has this issue come up in the past, and was a decision made to
> > keep sequences simple as an "int4" type only? Please clue me in on the
> > history. Is there any reason not to push forward with "int8" sequences,
> > as some sort of compile-time or run-time option?
> Mainly it's that int8 isn't supported on all our platforms. As a
> compile-time option it might be reasonable...
> regards, tom lane
Okay, cool. Similar subject: What about making the oid 64-bit? At first
glance, this seems easier to change than the sequence generator, since you
guys do a good job of using sizeof() and the Oid typedef. Changing the
typedef to "unsigned long long" should cover everything...? I will test
The snag I ran into with sequence.c is a missing Int64GetDatum() macro.
My system is Sun Solaris 7, compiled in 32-bit mode. So I
HAVE_LONG_LONG_INT_64 but don't HAVE_LONG_INT_64. I do have the "int8"
SQL datatype and tested it.
In c.h I have these lines:
typedef signed char int8; /* == 8 bits */
typedef signed short int16; /* == 16 bits */
typedef signed int int32; /* == 32 bits */
Is there some reason I'm missing the magic fourth line? It should be:
typedef signed long long int64; /* == 64 bits */
Isn't it strange I have the "int8" SQL datatype, but not the "int64" C
typedef and the Int64GetDatum() macro? I'm not a 64-bit compiling expert,
so go easy on me.
New Mexico Software
In response to
pgsql-hackers by date
|Next:||From: Ed Loehr||Date: 2000-06-23 18:16:13|
|Subject: Server process exited with status 139 (meaning?)|
|Previous:||From: Peter Eisentraut||Date: 2000-06-23 16:20:26|
|Subject: Re: Big 7.1 open items|