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 1jdImw-0006Z1-T0 for pgsql-hackers@arkaria.postgresql.org; Mon, 25 May 2020 19:29:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jdImv-0005gD-Ev for pgsql-hackers@arkaria.postgresql.org; Mon, 25 May 2020 19:29:29 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jdImu-0005g6-RA for pgsql-hackers@lists.postgresql.org; Mon, 25 May 2020 19:29:29 +0000 Received: from xvm-110-146.dc2.ghst.net ([46.226.110.146] helo=fetter.org) by magus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jdImq-0004n3-4p for pgsql-hackers@postgresql.org; Mon, 25 May 2020 19:29:28 +0000 Received: by fetter.org (Postfix, from userid 1001) id 034C640DAC; Mon, 25 May 2020 21:29:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fetter.org; s=default; t=1590434962; bh=jHr+MO35A3C1FHu6pJu9IkDE1dqBMD4oJfeeaB4S9js=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KaTqZY8iyWGOgPTrN8Sl21aKWhGxYB+lLZdSvgHS0DoY9A5LItDjpLHPY56ZSPrKn vkFWf4ghVMGp8YO5/nA6ARmscumG8cffW6ujEA1awkpYnqrrCY+A7yM8bnTtCsodlc FYOx4g2VKDBN7h/fcNi8U7EGPEZi2eYd4kdCYW/KiN3R6GfBkq+N16T9jD1q6kJYoY lMmXvaPl31kOaiWGl16Pu8wzARnpzKbsd00OGyXFL/VFLtJjzbT/LqO4AopbW6IO6f vxsElJw25yLNC4AfPIBNN32VCpXq+RfUBS2KHXBU++UeEAVvO87A2kGUjS7gwzaRrX dzeYpc13IzVDQ== Date: Mon, 25 May 2020 21:29:21 +0200 From: David Fetter To: Tom Lane Cc: Peter Eisentraut , Thomas Munro , Petr Fedorov , pgsql-hackers Subject: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch Message-ID: <20200525192921.GL13741@fetter.org> References: <42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu> <18389.1575241151@sss.pgh.pa.us> <1c2262e2-6812-7baa-cbdd-63039db12952@phystech.edu> <27490.1590414212@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27490.1590414212@sss.pgh.pa.us> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, May 25, 2020 at 09:43:32AM -0400, Tom Lane wrote: > 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. +1 for adding +/- infinity to NUMERIC. Best, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate