Robert Haas writes:
> On Wed, Aug 24, 2011 at 11:45 AM, Tom Lane wrote:
>> I kinda suspect that the NaN behavior was not designed but accidental.
>> What I'm wondering is whether it's really the "right", sensible,
>> behavior.
> On a blank slate, I might choose to do it differently, but consider
On Wed, Aug 24, 2011 at 11:45 AM, Tom Lane wrote:
> Euler Taveira de Oliveira writes:
>> Em 24-08-2011 11:27, Tom Lane escreveu:
>>> Hmm. I agree we need to avoid executing 0/0 here, but should we force
>>> the result to 0, or to NaN?
>
>> If it returns NaN on other platforms, let's be consisten
Euler Taveira de Oliveira writes:
> Em 24-08-2011 11:27, Tom Lane escreveu:
>> Hmm. I agree we need to avoid executing 0/0 here, but should we force
>> the result to 0, or to NaN?
> If it returns NaN on other platforms, let's be consistent.
I kinda suspect that the NaN behavior was not designed
Em 24-08-2011 11:27, Tom Lane escreveu:
Hmm. I agree we need to avoid executing 0/0 here, but should we force
the result to 0, or to NaN?
If it returns NaN on other platforms, let's be consistent.
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consult
Rushabh Lathia writes:
> After debugging I noticed that "0/0" returning NaN on linux but it returns
> "-1.#JIND" on windows.
[ rolls eyes ]
> I added to check into pgstatindex() to avoid "0/0" situation and issue got
> fixed.
Hmm. I agree we need to avoid executing 0/0 here, but should we
Description:
===
Error Message " invalid input syntax for type double precision: -1#I" is
displayed while running "select pgstatindex"
Issue only getting reproduce on windows environment.
Analysis:
=
Consider the following testcase to reproduce the issue on windows:
create tabl
