Re: Clarify: default precision on timestamps is 6

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kirk Parker <khp(at)equatoria(dot)us>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "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 20:37:53
Message-ID: 1571601.1697229473@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

Kirk Parker <khp(at)equatoria(dot)us> writes:
> On Fri, Oct 13, 2023 at 7:32 AM David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>> 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.

> 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:

The timestamp types don't have any explicit notion of precision
(unlike, say, numeric). The stored value is an integer number of
microseconds, nothing else. I've not checked the output function
recently but it makes sense to me that it'd just drop trailing
zeroes from the display, independently of any claimed precision
for the column. Meanwhile, when casting a timestamp value to
a declared precision, we handle that by just rounding off the
microseconds count. This doesn't buy any space savings or anything
like that, it's just for pro-forma compliance with the spec.

I don't see anything particularly wrong with the existing docs.
The limitation to 1-microsecond precision is spelled out in the
table just above the para you quote.

regards, tom lane

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message Tomas Pospisek 2023-10-14 14:58:46 Re: Make SSPI documentation clearer
Previous Message Daniel Fredouille 2023-10-13 19:33:57 Re: unnest multirange, returned order