>Thomas -
>A general design question. There seems to be a good reason to
>allow +/-Inf in float8 columns: Tim Allen has an need for them, for
>example. That's pretty straight forward, they seem to act properly if
>the underlying float libs handle them.
Thanks for pursuing this, Ross. I shall look forward to not having to use
a workaround in future versions.
>I'm not convinced NaN gives us anything useful, especially given how
>badly it breaks sorting. I've been digging into that code a little,
>and it's not going to be pretty. It strikes me as wrong to embed type
>specific info into the generic sorting routines.
Actually, we also have a use for NaN. The main thing we're using this for
is to store "fields", ie general descriptions of particular items of
metadata that occur in our application. Each field can have a validity
condition (ie min <= X <= max), and for open ranges we find the easiest
way to handle that without needing any extra bool flags or whatever is
just to set the minimum value to -infinity and/or the max to +infinity.
Our fields also have a default value, used in case the user didn't
actually enter anything. However, we want to be able to support something
like a NULL, so that if the user doesn't enter anything then in some cases
that means "there is no value". These values get passed around inside our
applications in various ways, in subsystems that don't have any direct
communication with the database, so using a database NULL doesn't do the
job. An NaN, however, is perfect for the job, because you can transmit
NaN's down sockets between processes, you can copy them around without
needing any special handling, and you can (currently) write them to and
read them from the database. So, for what it's worth, here's one vote for
keeping NaN's. As for sorting, we don't really care how they sort. Any
consistent behaviour will do for us.
Yes, there is a difference between an NaN and a NULL, but that difference
is not important in our application. We never do any serious arithmetic on
our float8 values, we just store them in the database and allow users to
view and edit the values.
>So, anyone have any ideas what NaN would be useful for? Especially given
>we have NULL available, which most (non DB) numeric applications don't.
It's this last point that makes NaN's useful; most non DB numeric
applications don't have a NULL, and NaN can make an adequate substitute.
One thing we could do, I suppose, is add code to our db interface layer to
translate NaN's to NULL's and vice versa. But if we don't have to, we'd be
happier :-).
>Ross
Tim
--
-----------------------------------------------
Tim Allen tim@proximity.com.au
Proximity Pty Ltd http://www.proximity.com.au/ http://www4.tpg.com.au/users/rita_tim/