Hi. A month or two ago I put an int8 data type into Postgres. Aside from
being useful on its own, it could also form the basis for other types
needing extended range, such as money, decimal, and numeric types (the
last two are SQL92 types).

Anyway, I implemented it on a gcc/x86/Linux machine, and we will need to
ensure that it works on other platforms. If you are doing any work at
all with a post-v6.3.2 source tree on another platform/OS combination,
can you please look at the results of the int8 regression test, or run
that test on your own, and let me know if it worked? If it didn't work,
then we should either put it on the list of things to do or make it work
in time for v6.4. But at the moment I don't know either way.

btw, there is a chance that the Alpha port will work since I coded for
it and I used to work on Alpha machines...

TIA

                     - Tom

Fri, 14 Aug 1998 15:46:53 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
int8 type -- call for porting results!
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> Anyway, I implemented it on a gcc/x86/Linux machine, and we will need to
> ensure that it works on other platforms. If you are doing any work at
> all with a post-v6.3.2 source tree on another platform/OS combination,
> can you please look at the results of the int8 regression test, or run
> that test on your own, and let me know if it worked?

It looks pretty broken on HPUX 9.03 (PA-RISC 1.1, gcc 2.7.2.2):

*** expected/int8.out	Wed Jul  8 10:29:08 1998
--- results/int8.out	Sat Aug 15 13:41:00 1998
***************
*** 6,115 ****
  QUERY: INSERT INTO INT8_TBL VALUES('4567890123456789','-4567890123456789');
  QUERY: SELECT * FROM INT8_TBL;
                q1|               q2
! ----------------+-----------------
               123|              456
!              123| 4567890123456789
! 4567890123456789|              123
! 4567890123456789| 4567890123456789
! 4567890123456789|-4567890123456789
  (5 rows)

[ much more in the same vein omitted ]
  
--- 6,117 ----
  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)

[ much more in the same vein omitted ]

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?

			regards, tom lane

Sat, 15 Aug 1998 13:59:46 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] int8 type -- call for porting results! 
> > 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

Sun, 16 Aug 1998 03:37:00 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] int8 type -- call for porting results!
I just started compiling the 6.4 snapshot from this weekend on our AIX 4.1.4
system.   I am running into problems surrounding snprintf().

1.  Do I need to set something in Makefile.global to activate the
compilation of snprintf()

2.  snprintf() does not compile clean.  It has several explicate referenced
to FILE data elements which are not on our FILE structure.   The error
messages follow:

       81 |         f._flags = __SWR | __SSTR;
            ........a..........b.......c......
a - 1506-022 (S) "_flags" is not a member of "struct {...}".
b - 1506-045 (S) Undeclared identifier __SWR.
c - 1506-045 (S) Undeclared identifier __SSTR.
       82 |         f._bf._base = f._p = (unsigned char *)str;
            ........a.............b...........................
a - 1506-022 (S) "_bf" is not a member of "struct {...}".
b - 1506-022 (S) "_p" is not a member of "struct {...}".
       83 |         f._bf._size = f._w = n;
            ........a.............b........
a - 1506-022 (S) "_bf" is not a member of "struct {...}".
b - 1506-022 (S) "_w" is not a member of "struct {...}".
       86 |                 *f._p = '\0';
            .................a...........
a - 1506-022 (S) "_p" is not a member of "struct {...}".
gmake: *** [snprintf.o] Error 1

This section does not look to portable.   I'm thinking that you could  use a
simple sprintf() in int8out() and made the buffer sufficiently big enough
that it could not overflow.   I will gladly submit a patch.

Please advise.

Thomas G. Lockhart wrote:

> Hi. A month or two ago I put an int8 data type into Postgres. Aside from
> being useful on its own, it could also form the basis for other types
> needing extended range, such as money, decimal, and numeric types (the
> last two are SQL92 types).
>
> Anyway, I implemented it on a gcc/x86/Linux machine, and we will need to
> ensure that it works on other platforms. If you are doing any work at
> all with a post-v6.3.2 source tree on another platform/OS combination,
> can you please look at the results of the int8 regression test, or run
> that test on your own, and let me know if it worked? If it didn't work,
> then we should either put it on the list of things to do or make it work
> in time for v6.4. But at the moment I don't know either way.
>
> btw, there is a chance that the Alpha port will work since I coded for
> it and I used to work on Alpha machines...
>
> TIA
>
>                      - Tom




Tue, 18 Aug 1998 12:59:08 -0400
David Hartwig <daveh@insightdist.com>
Re: [HACKERS] int8 type -- call for porting results!
On Tue, 18 Aug 1998, David Hartwig wrote:

> I just started compiling the 6.4 snapshot from this weekend on our AIX 4.1.4
> system.   I am running into problems surrounding snprintf().
> 
> 1.  Do I need to set something in Makefile.global to activate the
> compilation of snprintf()

	Let me check the code tonight from home, but there should be code
already for that.  It isn't in Makefile.global though, it should be
in...backend/ports/Makefile...



Tue, 18 Aug 1998 13:17:49 -0400 (EDT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] int8 type -- call for porting results!
The Hermit Hacker <scrappy@hub.org> writes:
> On Tue, 18 Aug 1998, David Hartwig wrote:
>> I just started compiling the 6.4 snapshot from this weekend on our AIX 4.1.4
>> system.   I am running into problems surrounding snprintf().
>> 
>> 1.  Do I need to set something in Makefile.global to activate the
>> compilation of snprintf()

Ah ... it's a typo in configure.in.

AC_CHECK_FUNC(snprintf,
	      AC_DEFINE(HAVE_SNPRINTF),
	      ISINF='snprintf.o')
AC_SUBST(SNPRINTF)

should read

AC_CHECK_FUNC(snprintf,
	      AC_DEFINE(HAVE_SNPRINTF),
	      SNPRINTF='snprintf.o')
AC_SUBST(SNPRINTF)


Looks like this has never worked, which makes me wonder how well
debugged our snprintf emulation is ... I guess David will test it
out for us ...

			regards, tom lane

Tue, 18 Aug 1998 15:09:06 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] int8 type -- call for porting results! 
> The Hermit Hacker <scrappy@hub.org> writes:
> > On Tue, 18 Aug 1998, David Hartwig wrote:
> >> I just started compiling the 6.4 snapshot from this weekend on our AIX 4.1.4
> >> system.   I am running into problems surrounding snprintf().
> >> 
> >> 1.  Do I need to set something in Makefile.global to activate the
> >> compilation of snprintf()
> 
> Ah ... it's a typo in configure.in.
> 
> AC_CHECK_FUNC(snprintf,
> 	      AC_DEFINE(HAVE_SNPRINTF),
> 	      ISINF='snprintf.o')
> AC_SUBST(SNPRINTF)
> 
> should read
> 
> AC_CHECK_FUNC(snprintf,
> 	      AC_DEFINE(HAVE_SNPRINTF),
> 	      SNPRINTF='snprintf.o')
> AC_SUBST(SNPRINTF)
> 
> 
> Looks like this has never worked, which makes me wonder how well
> debugged our snprintf emulation is ... I guess David will test it
> out for us ...

no code used snprintf until now.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Tue, 18 Aug 1998 17:26:53 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] int8 type -- call for porting results!
On Tue, 18 Aug 1998, Tom Lane wrote:

> Looks like this has never worked, which makes me wonder how well
> debugged our snprintf emulation is ... I guess David will test it
> out for us ...

	Fixed...

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Tue, 18 Aug 1998 21:16:20 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] int8 type -- call for porting results! 
Has this been fixed?


> I just started compiling the 6.4 snapshot from this weekend on our AIX 4.1.4
> system.   I am running into problems surrounding snprintf().
> 
> 1.  Do I need to set something in Makefile.global to activate the
> compilation of snprintf()
> 
> 2.  snprintf() does not compile clean.  It has several explicate referenced
> to FILE data elements which are not on our FILE structure.   The error
> messages follow:
> 
>        81 |         f._flags = __SWR | __SSTR;
>             ........a..........b.......c......
> a - 1506-022 (S) "_flags" is not a member of "struct {...}".
> b - 1506-045 (S) Undeclared identifier __SWR.
> c - 1506-045 (S) Undeclared identifier __SSTR.
>        82 |         f._bf._base = f._p = (unsigned char *)str;
>             ........a.............b...........................
> a - 1506-022 (S) "_bf" is not a member of "struct {...}".
> b - 1506-022 (S) "_p" is not a member of "struct {...}".
>        83 |         f._bf._size = f._w = n;
>             ........a.............b........
> a - 1506-022 (S) "_bf" is not a member of "struct {...}".
> b - 1506-022 (S) "_w" is not a member of "struct {...}".
>        86 |                 *f._p = '\0';
>             .................a...........
> a - 1506-022 (S) "_p" is not a member of "struct {...}".
> gmake: *** [snprintf.o] Error 1
> 
> This section does not look to portable.   I'm thinking that you could  use a
> simple sprintf() in int8out() and made the buffer sufficiently big enough
> that it could not overflow.   I will gladly submit a patch.
> 
> Please advise.
> 
> Thomas G. Lockhart wrote:
> 
> > Hi. A month or two ago I put an int8 data type into Postgres. Aside from
> > being useful on its own, it could also form the basis for other types
> > needing extended range, such as money, decimal, and numeric types (the
> > last two are SQL92 types).
> >
> > Anyway, I implemented it on a gcc/x86/Linux machine, and we will need to
> > ensure that it works on other platforms. If you are doing any work at
> > all with a post-v6.3.2 source tree on another platform/OS combination,
> > can you please look at the results of the int8 regression test, or run
> > that test on your own, and let me know if it worked? If it didn't work,
> > then we should either put it on the list of things to do or make it work
> > in time for v6.4. But at the moment I don't know either way.
> >
> > btw, there is a chance that the Alpha port will work since I coded for
> > it and I used to work on Alpha machines...
> >
> > TIA
> >
> >                      - Tom
> 
> 
> 
> 
> 


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Sun, 23 Aug 1998 21:05:29 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] int8 type -- call for porting results!