Thread: int8 type -- call for porting results!
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
"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
> > 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
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
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...
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
> 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)
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
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)