Re: [PATCH] Support empty ranges with bounds information

On Tue, Mar 2, 2021 at 4:57 PM Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
wrote:

>
>
> > On Mar 2, 2021, at 8:51 AM, Pantelis Theodosiou <ypercube(at)gmail(dot)com>
> wrote:
> >
> >
> >
> > On Tue, Mar 2, 2021 at 3:28 PM Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
> wrote:
> >
> >
> > > On Mar 2, 2021, at 5:20 AM, Joel Jacobson <joel(at)compiler(dot)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/4D5534D0020000250003A87E@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