> Note: When timestamp values are stored as double precision
> floating-point numbers (currently the default), the effective limit of
> precision may be less than 6. timestamp values are stored as seconds
> before or after midnight 2000-01-01. Microsecond precision is achieved
> for dates within a few years of 2000-01-01, but the precision degrades
> for dates further away. When timestamp values are stored as eight-byte
> integers (a compile-time option), microsecond precision is available
> over the full range of values.
I think this variance in precision is actually kind of cool - any
thought to allowing the "center" of the range to be a build-time
option? That is, any particular application might want more
precision at a custom center. Does this involve changing more than
that one constant?
Hmm, except if the timestamp "anchor" is installation-specific, then
binary exchange of timestamps is complicated. What does libpq do now
with timetamps, if the client requests data in binary form? How does
the client know whether it's getting floats or integers?
- John D. Burger
MITRE
