Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ibYBT-0003oW-F2 for pgsql-bugs@arkaria.postgresql.org; Sun, 01 Dec 2019 22:59:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ibYBR-0004uk-TF for pgsql-bugs@arkaria.postgresql.org; Sun, 01 Dec 2019 22:59:17 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ibYBR-0004ud-DJ for pgsql-bugs@lists.postgresql.org; Sun, 01 Dec 2019 22:59:17 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ibYBP-0003k2-4K for pgsql-bugs@postgresql.org; Sun, 01 Dec 2019 22:59:16 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id xB1MxB1r018390; Sun, 1 Dec 2019 17:59:11 -0500 From: Tom Lane To: Thomas Munro cc: Petr Fedorov , pgsql-bugs@postgresql.org Subject: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch In-reply-to: References: <42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu> Comments: In-reply-to Thomas Munro message dated "Mon, 02 Dec 2019 11:50:00 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18388.1575241151.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sun, 01 Dec 2019 17:59:11 -0500 Message-ID: <18389.1575241151@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Thomas Munro writes: > On Sat, Nov 30, 2019 at 10:28 PM Petr Fedorov wrote: >> Obviously, it is due to the fact that extract epoch returns double >> precision which in turn has 15 decimal digits precision. > I guess this deviation from the SQL standard ("exact numeric") made > sense when PostgreSQL used double for timestamps, but would break a > lot of queries if we changed it. Hmmm ... well, now that you mention it, would it really break things if we made it return numeric? There's an implicit cast to float8, so it seems like queries requiring that type would still work. There might be a performance-related argument against switching, perhaps. regards, tom lane