Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qrOv3-0045Lh-69 for pgsql-docs@arkaria.postgresql.org; Fri, 13 Oct 2023 20:38:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qrOv0-003W6Q-Ux for pgsql-docs@arkaria.postgresql.org; Fri, 13 Oct 2023 20:37:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qrOv0-003W6I-Nd for pgsql-docs@lists.postgresql.org; Fri, 13 Oct 2023 20:37:59 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qrOux-000OtT-Eg for pgsql-docs@lists.postgresql.org; Fri, 13 Oct 2023 20:37:58 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 39DKbr5n1571602; Fri, 13 Oct 2023 16:37:53 -0400 From: Tom Lane To: Kirk Parker cc: "David G. Johnston" , "him@nathanmlong.com" , "pgsql-docs@lists.postgresql.org" Subject: Re: Clarify: default precision on timestamps is 6 In-reply-to: References: <169719333062.169913.3076985245923767377@wrigleys.postgresql.org> Comments: In-reply-to Kirk Parker message dated "Fri, 13 Oct 2023 10:24:14 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <1571600.1697229473.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Fri, 13 Oct 2023 16:37:53 -0400 Message-ID: <1571601.1697229473@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Kirk Parker writes: > On Fri, Oct 13, 2023 at 7:32 AM David G. Johnston < > david.g.johnston@gmail.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