Re: int8 bug on Alpha
От | Thomas Lockhart |
---|---|
Тема | Re: int8 bug on Alpha |
Дата | |
Msg-id | 3AB8CD29.F34F9EA4@alumni.caltech.edu обсуждение исходный текст |
Ответ на | int8 bug on Alpha (Adriaan Joubert <a.joubert@albourne.com>) |
Ответы |
Re: Re: int8 bug on Alpha
Re: Re: int8 bug on Alpha |
Список | 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
В списке pgsql-hackers по дате отправления: