Re: [HACKERS] int8 type -- call for porting results! - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [HACKERS] int8 type -- call for porting results!
Date
Msg-id 35D653DC.193C9E02@alumni.caltech.edu
Whole thread Raw
In response to Re: [HACKERS] int8 type -- call for porting results!  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > I implemented it on a gcc/x86/Linux machine, and we will need to
> > ensure that it works on other platforms.
> It looks pretty broken on HPUX 9.03 (PA-RISC 1.1, gcc 2.7.2.2):
>   QUERY: INSERT INTO INT8_TBL
>   VALUES('4567890123456789','-4567890123456789');
>   QUERY: SELECT * FROM INT8_TBL;
>           q1|        q2
> ! ----------+----------
>          123|       456
> !        123|-869367531
> ! -869367531|       123
> ! -869367531|-869367531
> ! -869367531| 869367531
>   (5 rows)
> At a guess, something is getting cast to int32 somewhere along the
> line, or maybe the I/O conversion routines just don't work.
> Any thoughts where to look for the problem?

Sure. It will be easy to track down...

Here is the code in include/utils/int8.h:

#if defined(__alpha) || defined(PPC)
typedef long int int64;
#define INT64_FORMAT "%ld"

#elif defined(__GNUC__) && defined(i386)
typedef long long int int64;
#define INT64_FORMAT "%Ld"

#else
typedef long int int64;
#define INT64_FORMAT "%ld"
#endif

I didn't want to break everything all at once (I always prefer the slow
slide into full breakage :), so only enabled Alphas, PowerPCs (a dumb
mistake; I had thought that they were 64-bit machines), and gcc on x86
machines. Otherwise, the type gets defined as a "long int", which
probably will give you a 32-bit quantity.

OK, so GCC on 32-bit machines has a convention that "long long int" is a
64-bit quantity. On my machine there is library support for simple
64-bit integer math; we'll need to have addition, subtraction,
multiplication and division. I'll warn you that on a previous release of
gcc on my Linux box I had to poke around in obscure directories to find
the subtraction or division routine, but my more recent installations
seem to have all of the routines up in the normal places.

So, it may be sufficient for testing purposes to remove the
"&& defined(i386)" and see what you get. We can tailor the defines to
your machine later.

                      - Tom

pgsql-hackers by date:

Previous
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] geo_ops.c is broken
Next
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] Regression test status (was type coersion)