On Tue, Mar 2, 2021 at 4:57 PM Mark Dilger <mark.dil...@enterprisedb.com> wrote:
> > > > On Mar 2, 2021, at 8:51 AM, Pantelis Theodosiou <yperc...@gmail.com> > wrote: > > > > > > > > On Tue, Mar 2, 2021 at 3:28 PM Mark Dilger <mark.dil...@enterprisedb.com> > wrote: > > > > > > > On Mar 2, 2021, at 5:20 AM, Joel Jacobson <j...@compiler.org> wrote: > > > > > > it's currently not possible to create an empty range with bounds > information. > > > > > > This patch tries to improve the situation by keeping the bounds > information, > > > and allow accessing it via lower() and upper(). > > > > > > No other semantics have been changed. > > > All tests passes without any changes. > > > > I recall this issue of empty ranges not keeping any bounds information > being discussed back when range types were developed, and the design choice > was intentional. Searching the archives for that discussion, I don't find > anything, probably because I'm not searching for the right keywords. > Anybody have a link to that discussion? > > > > — > > Mark Dilger > > EnterpriseDB: http://www.enterprisedb.com > > The Enterprise PostgreSQL Company > > > > > > Marc, perhaps you were referring to this discussion? > > > https://www.postgresql.org/message-id/4d5534d0020000250003a...@gw.wicourts.gov > > Yes, I believe so. Thank you for the link. > Welcome. Also this message, where I found the link and has an overview of the different views at the time (and more links): https://www.postgresql.org/message-id/1299865026.3474.58.camel%40jdavis On Fri, 2011-03-11 at 08:37 -0500, Bruce Momjian wrote: > > Where are we on this? The options are: 1. Rip out empty ranges. Several > people have been skeptical of their > usefulness, but I don't recall anyone directly saying that they should > be removed. Robert Haas made the point that range types aren't closed > under UNION: > http://archives.postgresql.org/pgsql-hackers/2011-02/msg01045.php So the > additional nice mathematical properties provided by empty ranges > are not as important (because it wouldn't be perfect anyway). 2. Change > the semantics. Erik Rijkers suggested that we define all > operators for empty ranges, perhaps using NULL semantics: > http://archives.postgresql.org/pgsql-hackers/2011-02/msg00942.php And > Kevin Grittner suggested that there could be discrete ranges of zero > length yet a defined starting point: > http://archives.postgresql.org/pgsql-hackers/2011-02/msg01042.php 3. > Leave empty ranges with the existing "empty set" semantics. Nathan > Boley made a good point here: > http://archives.postgresql.org/pgsql-hackers/2011-02/msg01108.php Right > now it's #3, and I lean pretty strongly toward keeping it. Without > #3, people will get confused when fairly simple operations fail in a > data-dependent way (at runtime). With #3, people will run into problems > only in situations where it is fairly dubious to have an empty range > anyway (and therefore likely a real error), such as finding ranges "left > of" an empty range. Otherwise, I'd prefer #1 to #2. I think #2 is a bad > path to take, and > we'll end up with a lot of unintuitive and error-prone operators. Regards, > Jeff Davis
