Re: [PATCH] Fix for documentation of timestamp type

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

In response to

Responses

Browse pgsql-hackers by date

  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