Re: Re: [GENERAL] +/- Inf for float8's - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [GENERAL] +/- Inf for float8's
Date
Msg-id 26690.966835511@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [GENERAL] +/- Inf for float8's  ("Ross J. Reedstrom" <reedstrm@rice.edu>)
Responses Re: Re: [GENERAL] +/- Inf for float8's
Re: Re: [GENERAL] +/- Inf for float8's
List pgsql-hackers
"Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> !     switch (isinf(num))
> !     {
> !         case -1:
> !             PG_RETURN_CSTRING(strcpy(ascii, "-Infinity"));
> !             break;
> !         case 1:
> !             PG_RETURN_CSTRING(strcpy(ascii, "Infinity"));
> !             break;
> !         default:
> !             break;
> !     }

My man page for isinf() sez:
     isinf() returns a positive integer if x is +INFINITY, or a negative     integer if x is -INFINITY.  Otherwise it
returnszero.
 

so the above switch statement is making an unportable assumption about
exactly which positive or negative value will be returned.

> +     if (isnan(arg2)) PG_RETURN_BOOL(1); 

PG_RETURN_BOOL(true), please...

> !     if (isnan(a))
> !         PG_RETURN_INT32(1);

Do not like this at all --- doesn't it make the result of btint4cmp(NaN,
NaN) dependent on which argument chances to be first?  Seems to me that
you must consider two NaNs to be equal, unless you want to subdivide
the category of NaNs.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: BIT/BIT VARYING status
Next
From: Tom Lane
Date:
Subject: fmgr rewrite milestone