Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group