I'm working on the design for Range Types for 9.1:
http://wiki.postgresql.org/wiki/RangeTypes
But I think that floating-point timestamps may pose a problem. In this
thread:
http://archives.postgresql.org/pgsql-bugs/2010-08/msg00378.php
I pointed out that floating-point timestamps can become a different
value when dumped and reloaded (that is, the type input and output
functions are not perfect inverses).
This is a problem now, in theory, with UNIQUE indexes because the data
might be inserted once, but then a dump/reload may violate the
constraint. But it's not very common to include a high-precision
timestamp in a UNIQUE index, so it's not much of a practical problem.
However, with Exclusion Constraints and Range Types, I expect this
problem may become a practical problem, because Exclusion Constraints
are designed to work with things like timestamps. Also, with Range
Types, I expect people to generally care more about the precise
boundaries; so basic sanity (like input and output functions that are
inverses) seems more important.
What should be done? I see a few options:
1. Do nothing. Floating-point timestamps aren't the default, and the bug
reports are likely to be few and far between (but those that encounter
the bug are likely to be very frustrated).
2. Fix the input/output functions in a special mode for dump/reload, to
make them true inverses. This isn't easy to do by just adding extra
digits. But perhaps we could hack up the text format to have a special
escape that is really an encoded binary representation, or maybe
resembling float8.
3. Somehow deprecate floating point timestamps or make them unusable in
conjunction with Range Types. I'm not sure if there is demand to keep
them alive or not.
Thoughts?
Regards,Jeff Davis