From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Fix for documentation of timestamp type |
Date: | 2016-12-13 15:37:48 |
Message-ID: | CA+TgmoZy0v4NfEyX4jficwnn+TWP9b5CnH1H3FLmjqpYBdO9LQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 12, 2016 at 8:50 AM, Aleksander Alekseev
<a(dot)alekseev(at)postgrespro(dot)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 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 instead (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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-12-13 15:39:57 | Re: Declarative partitioning - another take |
Previous Message | Tom Lane | 2016-12-13 15:33:56 | Re: pg_catversion builtin function |