The following bug has been logged online:

Bug reference: 2111
Logged by: Neil Parker
Email address: nparker (AT) microniche (DOT) com
PostgreSQL version: 8.1.1
Operating system: Linux (Slackware 8.0, with kernel 2.2.19, glibc 2.2.3)
Description: Error parsing 'infinity' under some versions of glibc
Details:

PostgreSQL fails to parse the string 'infinity' as a floating point number
under some versions of glibc on Linux.

To reproduce:
* Unpack PostgreSQL 8.1.1 on a Linux system with glibc-2.2.3.
* configure
* make
* make check
* watch as it complains "float4 .. FAILED" and "float8 .. FAILED".

Looking in regressions.diffs, the problems begin with
SELECT 'infinity'::float4;
This is supposed to return
float4
----------
Infinity
(1 row)
Instead it produces
ERROR: invalid input syntax for type real: "infinity"
All the other tests of 'Infinity' fail the same way, and likewise with
float8.


This problem appears to be glibc's fault, not PostgreSQL's. In version
2.2.3 of glibc, strtod()
parses "inf" as infinity, but (contrary to the documentation) it stops there
and doesn't go on to check whether the input string is the full word
"infinity".

The following C code shows the problem:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
char *num = "Infinity";
char *endptr;
double d;

d = strtod(num, &endptr);
printf("result is %f, len is %d\n", d, endptr-num);
exit(0);
}

If this is compiled and run under glibc 2.2.3, the output is "result is inf,
len is 3".

The problem is fixed in later versions of glibc...the output under glibc
2.3.2 is "result is inf, len is 8".

Below is a patch that fixes the problem on the affected system. It's at
best a stopgap, and I can't guarantee that it won't break floating-point
parsing on other systems, but with this in place PostgreSQL passes all its
regression tests on the affected system.

*** postgresql-8.1.1/src/backend/utils/adt/float.c.orig Fri Oct 14 19:49:28
2005
--- postgresql-8.1.1/src/backend/utils/adt/float.c Tue Dec 13 11:31:03
2005
***************
*** 282,288 ****
val = strtod(num, &endptr);

/* did we not see anything that looks like a double? */
! if (endptr == num || errno != 0)
{
/*
* C99 requires that strtod() accept NaN and [-]Infinity,
but not all
--- 282,288 ----
val = strtod(num, &endptr);

/* did we not see anything that looks like a double? */
! if (is_infinite(val) || endptr == num || errno != 0)
{
/*
* C99 requires that strtod() accept NaN and [-]Infinity,
but not all
***************
*** 449,455 ****
val = strtod(num, &endptr);

/* did we not see anything that looks like a double? */
! if (endptr == num || errno != 0)
{
/*
* C99 requires that strtod() accept NaN and [-]Infinity,
but not all
--- 449,455 ----
val = strtod(num, &endptr);

/* did we not see anything that looks like a double? */
! if (is_infinite(val) || endptr == num || errno != 0)
{
/*
* C99 requires that strtod() accept NaN and [-]Infinity,
but not all

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

"Neil Parker" <nparker (AT) microniche (DOT) com> writes:
Indeed, so why are you complaining to us?

I'm fairly unenthused about a kluge that hurts performance on
standard-conforming systems (by forcing them to traverse the slow code
path) in order to cater to a long-obsolete glibc whose behavior conforms
to neither the C standard nor its own documentation. If this bug is a
problem for you, update glibc.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster