The latest patch attachment has a couple typos in it ("storead" instead of "stored"). I interpreted the final
suggestionin the thread to mean 1) default stores in microseconds 2) deprecated compile-time option stores as seconds.
Ifthese assumptions are correct then the suggestion in the thread (minus "instead" as Tom suggested) provided below
shouldbe 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
availableover the full range of values. In this case, the internal representation is the number of microseconds before
orafter midnight 2000-01-01. When <type>timestamp</> values are stored as double precision floating-point numbers (a
deprecatedcompile-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
precisionis achieved for dates within a few years of 2000-01-01, but the precision degrades for dates further away.
Notethat using floating-point datetimes allows a larger range of <type>timestamp</type> values to be represented than
shownabove: from 4713 BC up to 5874897 AD.
Thanks,
-Cynthia
