From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ryan Kirkpatrick <pgsql(at)rkirkpat(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, pgsql-ports(at)postgresql(dot)org |
Subject: | Re: PostgreSQL pre-7.1 Linux/Alpha Status... |
Date: | 2000-12-20 16:41:13 |
Message-ID: | 5546.977330473@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-ports |
Ryan Kirkpatrick <pgsql(at)rkirkpat(dot)net> writes:
> INSERT INTO OID_TBL(f1) VALUES ('-1040');
> ERROR: oidin: error reading "-1040": value too large
That's coming from a possibly-misguided error check that I put into
oidin():
unsigned long cvt;
char *endptr;
cvt = strtoul(s, &endptr, 10);
...
/*
* Cope with possibility that unsigned long is wider than Oid.
*/
result = (Oid) cvt;
if ((unsigned long) result != cvt)
elog(ERROR, "oidin: error reading \"%s\": value too large", s);
On a 32-bit machine, -1040 converts to 4294966256, but on a 64-bit
machine it converts to 2^64-1040, and the test is accordingly deciding
that that value won't fit in an Oid.
Not sure what to do about this. If you had actually typed 2^64-1040,
it would be appropriate for the code to reject it. But I hadn't
realized that the extra check would introduce a discrepancy between
32- and 64-bit machines for negative inputs. Maybe it'd be better just
to delete the check. Comments anyone?
> SELECT p.name, p.hobbies.name FROM person* p;
> pqReadData() -- backend closed the channel unexpectedly.
Backtrace please?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Paul A Vixie | 2000-12-20 16:53:09 | day 2 results |
Previous Message | Magnus Hagander | 2000-12-20 16:26:01 | RE: SSL Connections |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Naeslund(f) | 2000-12-20 16:58:27 | Re: PostgreSQL pre-7.1 Linux/Alpha Status... |
Previous Message | Ryan Kirkpatrick | 2000-12-20 04:08:00 | PostgreSQL pre-7.1 Linux/Alpha Status... |