Re: SELECT '(1, nan, 3)'::cube;

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Robert Brewer" <fumanchu(at)aminus(dot)org>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: SELECT '(1, nan, 3)'::cube;
Date: 2011-03-15 18:43:40
Message-ID: 2336.1300214620@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Robert Brewer" <fumanchu(at)aminus(dot)org> writes:
> Tom Lane wrote:
>> I'd suggest rethinking your design to avoid needing NaN in a cube.

> I could, of course, use a sentinel value like -1 or even -Inf to mean
> "indeterminate", but I'd like future versions of this app (wink) to be
> able to use qnan's as IEEE 754 intended. Note that cube doesn't take
> NULL either. It may be surprising and underspecified, but using NaN and
> Inf in other cube operations (including gist indices) does indeed work
> quite well--probably because they are, after all, just floats. I believe
> it's a bug to handle only some subset of values of an extremely
> well-known and well-specified datatype like float, but of course I
> understand if contrib modules aren't high priority.

Well, this is the sort of thing that'll only get fixed when someone who
actually uses the datatype is motivated to improve it. IOW, if you
submitted a patch it'd likely get accepted.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Andy Lester 2011-03-15 22:23:14 BUG #5932: CLUSTER doesn't update n_dead_tup
Previous Message Robert Brewer 2011-03-15 17:54:22 Re: SELECT '(1, nan, 3)'::cube;