Date: Sat, 26 Oct 2019 16:15:29 +0300
From: Eugen Konkov <kes-kes@yandex.ru>
Message-ID: <376945611.20191026161529@yandex.ru>
Disposition-Notification-To: kes-kes@yandex.ru
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-docs@lists.postgresql.org
Subject: Re: Why 'infinity' is not in range '[2019-01-02, infinity]'?
In-Reply-To: <7991.1556573455@sss.pgh.pa.us>
References: <155655432452.1371.6115195379691603427@wrigleys.postgresql.org>
  <5f6b986b-de4d-8a43-1366-fc8c3aed6319@postgresql.org>
  <1265663903.20190429212216@yandex.ru> <7991.1556573455@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1250
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Today I got next ambiguous:

select tstzrange( 'infinity', null );
  tstzrange =20
-------------
 [infinity,)
(1 row)

[DOC](https://www.postgresql.org/docs/12/rangetypes.html) stated:
>if the upper bound of the range is omitted, then all points greater than t=
he lower bound are included in the range.
>This is equivalent to considering that the upper bound is =93plus infinity=
=94, respectively.

Thus I can write, can not?

select tstzrange( 'infinity', 'infinity' );
  tstzrange =20
-------------
 empty
(1 row)

But thus it is not not equivalent.


>But note that these infinite values are never values of the range's elemen=
t type, and can never be part of the range
Thus if 'infinite values are never values of the range' then

=93infinity=94 can not be just another value of any range type
This conclusion contradicts next doc paragraph:
>Also, some element types have a notion of =93infinity=94, but that is just=
 another value so far as the range type mechanisms are concerned.

errr...   mechanism  of  date  ranges  violates basic rules  for  'Infinite
(Unbounded) Ranges'?


--=20
Best regards,
Eugen Konkov