Jeff Davis <pgsql@j-davis.com> writes:
> On Wed, 2009-12-16 at 13:59 -0500, Tom Lane wrote:
>> The argument for having
>> granularity wired into the datatype seems to boil down to just space
>> savings. I don't find that compelling enough to justify code
>> contortions and user-visible restrictions on functionality.
> The argument (at least from me) is that discrete ranges have better
> semantics. The counterargument was that the granularity of a timestamp
> is an implementation detail. So I countered by making it explicit.
Making it explicit doesn't fix the fact that you can't rely on the
arithmetic to be exact.
> I still have not seen an answer to the problem of changing the
> representation of a continuous range. If you have the continuous range
> [5, 10], you're pretty much stuck with that representation, even if the
> application is expecting things in the form [ ).
That is not our problem. It's the application's problem if it can't
handle the concept. You might as well be complaining that type numeric
is broken because it can represent values that will fail to fit into
float8 when some application tries to force them into that form.
> And to further make the case for allowing user-defined discrete ranges,
> what about ip4r?
What about it? I don't have a problem with the concept that next() is
well defined for some datatypes. I just have a problem with the concept
that it's well-defined for timestamps. It's not, and I don't believe
that forcing it to have some definition is useful in the real world
(which, as a rule, isn't going to fit the simplifying assumptions you
have to make to make it even sort-of work).
regards, tom lane