From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | lockhart(at)fourpalms(dot)org |
Cc: | Adriaan Joubert <a(dot)joubert(at)albourne(dot)com>, Postgresql <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: int8 bug on Alpha |
Date: | 2001-03-22 03:39:11 |
Message-ID: | 2987.985232351@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> 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!
Ohhhh....
This is an Alpha, remember? long *is* 64 bits on that machine,
therefore strtol is correct to accept the number. Unfortunately,
later in the parser we assign the datatype int4, not int8, to the
"integer" constant, and so it gets truncated. make_const is making
an unwarranted assumption that T_Integer is the same as int4 --- or,
if you prefer, make_const is OK and scan.l is erroneous to use
node type T_Integer for ints that exceed 32 bits.
This is a portability bug, no question. But I'd expect it to fail
like that on all Alpha-based platforms. Adriaan, when you say it
works on Linux, are you talking about Linux/Alpha or some other
hardware?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-03-22 03:47:31 | Re: BufferSync() & FlushRelationBuffers() conflict |
Previous Message | Larry Rosenman | 2001-03-22 03:31:09 | Re: Call for platforms |