Tom Lane wrote:
Jeff Davis <pg...@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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
