Re: Range types

Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
>> On Tue, 2009-12-15 at 11:49 -0800, David Fetter wrote:
>>> FWIW, I think it would be a good idea to treat timestamps as
>>> continuous in all cases.
> 
>> I disagree. There is a lot of value in treating timestamp ranges as
>> discrete.
> 
>> One big reason is that the ranges can be translated between the
>> different input/output forms, and there's a canonical form. As we know,
>> a huge amount of the value in an RDBMS is unifying data from multiple
>> applications with different conventions.
> 
> Actually, that is exactly one of the reasons why what you propose is
> a *bad* idea.  You want to institutionalize application dependence on
> a non-portable implementation detail, namely the granularity of machine
> representation of what's in principle a continuous value.  That's one
> of the fastest routes to non-unifiable data I can think of.
> 
>> So, let's say one application uses (] and another uses [). If you are
>> mixing the data and returning it to the application, you want to be able
>> to provide the result according to its convention. You can't do that
>> with a continuous range.
> 
> The above is nonsense.  [1,2) and [1,2] are simply different objects.
> A design that assumes that it is always possible to replace one by
> the other is broken so badly it's not even worth discussing.

I don't hear anyone arguing that. But you should be able to convert 
between [1,2], [1,3), (0,3) and (0,2].

> The only reason you'd have applications that fail to handle both open
> and closed intervals would be if someone were to create an
> implementation that didn't support both from the outset.  Which we
> need not and should not do.
> 
>> And things get more interesting: if you mix (] and [), then range_union
>> will produce () and range_intersect will produce []. So now you have all
>> four conventions floating around the same database.
> 
> Which is why it's a good idea to support all four...

I don't understand you then. Where do you suppose we would define the 
inclusiveness for the value? At the type level, at the column level, or 
at the value level? A design that allows values of different 
inclusiveness and offers no means to convert from one to another is 
worthless.