
> 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?

IIRC oid uses int4in/int4out and those should definitely be able to parse 
-1040 into a 4 byte signed long without platform dependency, no ?

pg_dump with OID's dumps those negative numbers if oid > 2^32,
thus this input must imho be made to work correctly.

Andreas

Thu, 21 Dec 2000 11:53:11 +0100
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: PostgreSQL pre-7.1 Linux/Alpha Status... 
> IIRC oid uses int4in/int4out and those should definitely be able to parse
> -1040 into a 4 byte signed long without platform dependency, no ?

Tom Lane changed this recently to have OID use its own i/o routines.

                     - Thomas

Thu, 21 Dec 2000 14:54:10 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: AW: [HACKERS] PostgreSQL pre-7.1 Linux/Alpha Status...
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
> IIRC oid uses int4in/int4out and those should definitely be able to parse 
> -1040 into a 4 byte signed long without platform dependency, no ?

It has done that in past releases.  I changed it to use unsigned display
for 7.1.  Because of the past behavior, I think oidin had better accept
negative inputs for backwards compatibility.  Besides which, strtoul()
does that naturally ...

			regards, tom lane

Thu, 21 Dec 2000 10:24:44 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: PostgreSQL pre-7.1 Linux/Alpha Status... 