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 1hLDrZ-0000w2-Qo for pgsql-docs@arkaria.postgresql.org; Mon, 29 Apr 2019 21:31:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hLDrY-0006RB-Lb for pgsql-docs@arkaria.postgresql.org; Mon, 29 Apr 2019 21:31:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hLDrY-0006R4-EX for pgsql-docs@lists.postgresql.org; Mon, 29 Apr 2019 21:31:00 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hLDrW-0002Bj-FT for pgsql-docs@lists.postgresql.org; Mon, 29 Apr 2019 21:31:00 +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 x3TLUtuN007992; Mon, 29 Apr 2019 17:30:56 -0400 From: Tom Lane To: Eugen Konkov cc: pgsql-docs@lists.postgresql.org Subject: Re: Why 'infinity' is not in range '[2019-01-02, infinity]'? In-reply-to: <1265663903.20190429212216@yandex.ru> References: <155655432452.1371.6115195379691603427@wrigleys.postgresql.org> <5f6b986b-de4d-8a43-1366-fc8c3aed6319@postgresql.org> <1265663903.20190429212216@yandex.ru> Comments: In-reply-to Eugen Konkov message dated "Mon, 29 Apr 2019 21:22:16 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7990.1556573455.1@sss.pgh.pa.us> Date: Mon, 29 Apr 2019 17:30:55 -0400 Message-ID: <7991.1556573455@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Eugen Konkov writes: > if you allow I will suggest to map/convert 'infinity' value to > unbound range, for datatypes which defines 'infinity' value. That was intentionally rejected in the original range types design, and even if we thought that decision was wrong, it's too late to change it now. There's probably some merit in having the documentation avoid the use of "infinity" when it really means "unbounded", but I'm not sure we can avoid it altogether without being obscure. regards, tom lane