David Fetter <david@fetter.org> writes:
> On Sun, Oct 24, 2010 at 06:59:34PM -0400, Tom Lane wrote:
>> Put me in the camp that says you need both. I really seriously
>> dislike the idea of representing [1, 2) as [1, 2-epsilon], mainly
>> because there is often no portable value for epsilon.
>> Dump-and-restore would be quite hazardous.
> It wouldn't be stored as (1, 2-epsilon). It would be stored more like
> (1, 2, closed, open).
Fine ...
> If you have a coherent, worked-out theory of continuous ranges, please
> feel free to develop and publish it just as Snodgrass, et al., have
> done with discrete ranges, but please *don't* feel free to assume that
> you can just wave a magic wand and make continuous time ranges "just
> work" because it pleases you aesthetically.
That is FUD, and nothing more. If you know a concrete reason why
Postgres shouldn't provide both closed and open ranges, you need to
explain it, not claim that there might be a reason someplace and it's
someone else's problem to prove your point for you.
I don't have any problem with specific operations failing for open-ended
ranges, if there isn't a meaningful result for the case; but that
doesn't lead me to the conclusion that every operation is meaningless
for open-ended ranges.
>> But the real problem is that if the user wants to think in terms of
>> continuous ranges, the only way that he can convert those to
>> discrete ranges is to assume an epsilon for the datatype, and he
>> shouldn't be forced to do that; not even if the datatype does have a
>> well-defined epsilon at the implementation level, which several of
>> ours don't..
> They're all well defined, but not uniform.
And that's not even FUD, it's simply wrong. Even if you're prepared to
claim that users should understand the precise behavior of their local
floating-point type, what about NUMERIC?
regards, tom lane