From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Adriaan Joubert <a(dot)joubert(at)albourne(dot)com> |
Cc: | lockhart(at)fourpalms(dot)org, Postgresql <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: int8 bug on Alpha |
Date: | 2001-03-21 15:47:54 |
Message-ID: | 3AB8CD29.F34F9EA4@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > How are you doing the inserts? If you aren't coercing the "2" to be an
> > int8, then (afaik) the math will be done in int4, then upconverted. So,
> > can you confirm that your inserts look like:
> > insert into lint values ('9223372036854775807');
> OK, that was it. I inserted without quotes. If I insert the quotes it
> works. So why does it work correctly on linux without quotes?
For integers (optional sign and all digits), the code in
src/backend/parser/scan.l uses strtol() to read the string, then checks
for failure. If it fails, the number is interpreted as a double float on
the assumption that if it could hold more digits it would succeed!
Anyway, either strtol() thinks it *should* be able to read a 64 bit
integer, or your machine is silently overflowing. I used to have a bunch
of these boxes, and I recall spending quite a bit of time discovering
that Alphas have some explicit flags which can be set at compile time
which affect run-time detection of floating point and (perhaps) integer
overflow behavior.
Can you check these possibilities? I'd look at strtol() first, then the
overflow/underflow flags second...
- Thomas
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-03-21 15:51:03 | New TODO item |
Previous Message | Trond Eivind =?iso-8859-1?q?Glomsr=F8d?= | 2001-03-21 15:12:40 | Re: RPM building (was regression on RedHat) |