Обсуждение: Re: [HACKERS] [PATCH] Fix for documentation of timestamp type
On Mon, Dec 12, 2016 at 8:50 AM, Aleksander Alekseev <a.alekseev@postgrespro.ru> wrote: > I suggest to rewrite the documentation a bit to make it more clear that > by default timestamp is stored in microseconds. Corresponding patch is > attached. I find this a bit unclear, because the revised text kind of jumps back and forth between the floating-point and integer formats. Perhaps something like this: 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 beforeor after midnight 2000-01-01. When <type>timestamp</> values are stored as double precision floating-point numbersinstead (a deprecated compile-time option), the internal representation is the number of seconds before or aftermidnight 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 fordates further away. Note that using floating-point datetimes allows a larger range of <type>timestamp</type> valuesto be represented than shown above: from 4713 BC up to 5874897 AD. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> I find this a bit unclear, because the revised text kind of jumps back
> and forth between the floating-point and integer formats. Perhaps
> something like this:
Your wording seems OK to me, although I'd drop the "instead".
regards, tom lane
On Tue, Dec 13, 2016 at 10:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> I find this a bit unclear, because the revised text kind of jumps back >> and forth between the floating-point and integer formats. Perhaps >> something like this: > > Your wording seems OK to me, although I'd drop the "instead". Good idea. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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
On Tue, Dec 13, 2016 at 10:46 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Dec 13, 2016 at 10:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> I find this a bit unclear, because the revised text kind of jumps back >>> and forth between the floating-point and integer formats. Perhaps >>> something like this: >> >> Your wording seems OK to me, although I'd drop the "instead". > > Good idea. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company