From: | Kirk Parker <khp(at)equatoria(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | "him(at)nathanmlong(dot)com" <him(at)nathanmlong(dot)com>, "pgsql-docs(at)lists(dot)postgresql(dot)org" <pgsql-docs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Clarify: default precision on timestamps is 6 |
Date: | 2023-10-13 17:24:14 |
Message-ID: | CANwZ8r=5DFNcy70__Aeo58+rFysT1B=gEuzesoH5xpZ61tNFyA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On Fri, Oct 13, 2023 at 7:32 AM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> On Friday, October 13, 2023, PG Doc comments form <noreply(at)postgresql(dot)org>
> wrote:
>
>> both of them round any precision
>> beyond microseconds, and neither returns timestamps with greater precision
>> than the value that was inserted.
>>
>
> That is precisely what a no default with maximum of six means. If we say
> the default is six that would imply storage of less precise values pads
> significant zeros until there are six.
>
> David J.
>
>
Not sure that last statement is correct. In 13 (only system I have access
to at the moment) it doesn't look like casting to a precision greater than
the value originally had causes any padding:
some_system=# select CURRENT_TIMESTAMP(0)::timestamp(6) with time zone;
current_timestamp
------------------------
2023-10-13 17:19:00+00
(1 row)
some_system=# select CURRENT_TIMESTAMP(1)::timestamp(6) with time zone;
current_timestamp
--------------------------
2023-10-13 17:23:04.2+00
(1 row)
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Fredouille | 2023-10-13 19:33:57 | Re: unnest multirange, returned order |
Previous Message | Nathan Long | 2023-10-13 14:54:22 | Re: Clarify: default precision on timestamps is 6 |