| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Windows env returns error while running "select pgstatindex" |
| Date: | 2011-08-24 18:07:01 |
| Message-ID: | 16166.1314209221@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Aug 24, 2011 at 11:45 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 considering
> that we have numerous releases out in the field that return NaN, I
> think we should stick with that rather than using this minor bug as an
> excuse to change the answer on platforms where this isn't already
> broken.
[ pokes at it... ] Hmm, you're right, everything back to 8.2 produces
NaNs on this test case (at least on IEEE-compliant platforms). I yield
to the "let's emit NaN" viewpoint.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Farina | 2011-08-24 18:24:49 | Should I implement DROP INDEX CONCURRENTLY? |
| Previous Message | Robert Haas | 2011-08-24 17:20:12 | Re: Windows env returns error while running "select pgstatindex" |