Re: Range types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: tomas(at)tuxteam(dot)de, Jeff Davis <pgsql(at)j-davis(dot)com>, Scott Bailey <artacus(at)comcast(dot)net>, hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Range types
Date: 2009-12-15 14:58:28
Message-ID: 15105.1260889108@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <gsstark(at)mit(dot)edu> writes:
> In fact, as I only recently found out, one of the design goals of IEEE
> floats was specifically that they sort lexicographically and use every
> bit pattern. So you can alwys get the "next" float by just
> incrementing your float as an 64-bit integer. Yes that raises your
> value by a different amount, and it's still useful.

There are certainly some low-level numerical analysis situations where
you want to get the "next" float value, but that hardly constitutes
an argument for treating ranges of floats as discrete rather than
continuous. Normal users of a range datatype aren't going to be
interested in dealing with that sort of inherently machine-specific
behavior.

Even in types where next/previous are well defined, I'm not that
comfortable with having range operations depend on them. What happens
when one end of your range is INT_MIN or INT_MAX?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-12-15 15:02:04 Re: Compiling HEAD with -Werror int 64-bit mode
Previous Message Tom Lane 2009-12-15 14:52:40 Re: Range types