The latest patch attachment has a couple typos in it ("storead" instead of
"stored"). I interpreted the final suggestion in the thread to mean 1) default
stores in microseconds 2) deprecated compile-time option stores as seconds. If
these assumptions are correct then the suggestion in the thread (minus
"instead" as Tom suggested) provided below should be incorporated and attached
as a patch to this thread. Therefore I recommend an "Awaiting Author" status.
When <type>timestamp</> values are stored as eight-byte integers (currently the
default), microsecond precision is available over the full range of values. In
this case, the internal representation is the number of microseconds before or
after midnight 2000-01-01. When <type>timestamp</> values are stored as double
precision floating-point numbers (a deprecated compile-time option), the
internal representation is the number of seconds before or after midnight
2000-01-01. With this representation, the effective limit of precision might
be less than 6; in practice, microsecond precision is achieved for dates within
a few years of 2000-01-01, but the precision degrades for dates further away.
Note that using floating-point datetimes allows a larger range of
<type>timestamp</type> values to be represented than shown above: from 4713 BC
up to 5874897 AD.
Thanks,
-Cynthia
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
