On Tue, 2009-12-15 at 17:17 -0500, Tom Lane wrote:
> 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.
Based on the premise that timestamps are a continuous value and the
granularity/precision is entirely an implementation detail, you're
right. But I disagree with the premise, at least in some cases that I
think are worthwhile. See reference [1].
> 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 understand this point at all. [1,2) and [1,2] are different
values. Of course they are not interchangeable.
If you think I'm proposing that we drop inclusivity/exclusivity before
telling the application, that's not what I'm proposing at all. I'm
proposing that, at least in some circumstances, it's important to be
able to display the same value in different formats -- e.g. [1, 3) or
[1, 2], depending on what the application expects. Similar to a timezone
adjustment.
Regards,Jeff Davis
[1] "Temporal Data and the Relational Model" by C.J. Date, et al., uses
discrete time throughout the entire book, aside from a brief discussion
at the beginning.
