Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jdDOJ-00081m-MV for pgsql-hackers@arkaria.postgresql.org; Mon, 25 May 2020 13:43:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jdDOI-0002WR-K9 for pgsql-hackers@arkaria.postgresql.org; Mon, 25 May 2020 13:43:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jdDOI-0002WK-DN for pgsql-hackers@lists.postgresql.org; Mon, 25 May 2020 13:43:42 +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 1jdDOC-0008J4-1Z for pgsql-hackers@postgresql.org; Mon, 25 May 2020 13:43:41 +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 04PDhWcg027491; Mon, 25 May 2020 09:43:32 -0400 From: Tom Lane To: Peter Eisentraut cc: Thomas Munro , Petr Fedorov , pgsql-hackers 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> <18389.1575241151@sss.pgh.pa.us> <1c2262e2-6812-7baa-cbdd-63039db12952@phystech.edu> Comments: In-reply-to Peter Eisentraut message dated "Mon, 25 May 2020 15:28:54 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27489.1590414212.1@sss.pgh.pa.us> Date: Mon, 25 May 2020 09:43:32 -0400 Message-ID: <27490.1590414212@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Peter Eisentraut writes: > One problem (other than perhaps performance, tbd.) is that this would no > longer allow processing infinite timestamps, since numeric does not > support infinity. It could be argued that running extract() on infinite > timestamps isn't very useful, but it's something to consider explicitly. I wonder if it's time to fix that, ie introduce +-Infinity into numeric.c. This isn't the first time we've seen issues with numeric not being a superset of float, and it won't be the last. At first glance there's no free bits in the on-disk format for numeric, but we could do something by defining the low-order bits of the header word for a NaN to distinguish between real NaN and +/- infinity. It looks like those bits should reliably be zero right now. regards, tom lane