On Mon, Mar 11, 2019 at 8:45 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Michael Paquier <mich...@paquier.xyz> writes: > > On Sun, Mar 10, 2019 at 07:18:20PM +0000, Tom Lane wrote: > I think what's going on here is what's mentioned in the comments in > float8in_internal: > > * C99 requires that strtod() accept NaN, [+-]Infinity, and [+-]Inf, > * but not all platforms support all of these (and some accept them > * but set ERANGE anyway...) > > Specifically, these symptoms would be explained if these platforms' > strtod() sets ERANGE for infinity. > > I can think of three plausible responses. In decreasing order of > amount of work: > > 1. Decide that we'd better wrap strtod() with something that ensures > platform-independent behavior for all our uses of strtod (and strtof?) > rather than only float8in_internal. >
This sounds like a good approach, but won't it has the risk of change in behaviour? > 2. Put in a hack in guc.c to make it ignore ERANGE as long as the result > satisfies isinf(). This would ensure GUC cases would go through the > value-out-of-range path rather than the syntax-error path. We've got > a bunch of other strtod() calls that are potentially subject to similar > platform dependencies though ... > Yeah, this won't completely fix the symptom. > 3. Decide this isn't worth avoiding platform dependencies for, and just > take out the new regression test case. I'd only put in that test on > the spur of the moment anyway, so it's hard to argue that it's worth > much. > For the time being option-3 sounds like a reasonable approach to fix buildfarm failures and then later if we want to do some bigger surgery based on option-1 or some other option, we can anyways do it. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
