Re: [PATCH] Support empty ranges with bounds information

From: "Joel Jacobson" <joel(at)compiler(dot)org>
To: "Pantelis Theodosiou" <ypercube(at)gmail(dot)com>, "Mark Dilger" <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: "Postgres hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Isaac Morland" <isaac(dot)morland(at)gmail(dot)com>
Subject: Re: [PATCH] Support empty ranges with bounds information
Date: 2021-03-02 19:14:25
Message-ID: dd60c13a-e94c-40e8-bd55-2b95a2b04912@www.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 2, 2021, at 17:51, Pantelis Theodosiou wrote:
> Marc, perhaps you were referring to this discussion?
> https://www.postgresql.org/message-id/4D5534D0020000250003A87E@gw.wicourts.gov

I've read through the "Re: Range Types: empty ranges" thread from 2011.

My comments:

Jeff Davis wrote:
>The cost, of course, is that not all operations are well-defined for
>empty ranges. I think those are mostly operators like those mentioned in
>the other thread: ">>" (strictly right of), "<<" (strictly left of), and
>"-|-" (adjacent); and perhaps "&>" and "&<". These are probably used a
>little less frequently, and should probably not be used in a context
>where empty ranges are permitted (if they are, it's likely a mistake and
>an error should be thrown).

Interesting. I realize all of these operators would actually be well defined for empty ranges *with* bounds information.

"Kevin Grittner" wrote:
>Perhaps it was a mistake to get so concrete rather than conceptual
>-- basically, it seems like it could be a useful concept for any
>planned or scheduled range with an indeterminate end point, which
>you want to "reserve" up front and record in progress until
>complete. The alternative would be that such "ranges to be" have a
>parallel "planned start value" column of the same type as the range,
>to be used as the start of the range once it is not empty. Or, as
>another way to put it, it seems potentially useful to me to have an
>empty range which is pinned to a location, in *addition* to the
>unpinned empty ranges such as would be needed to represent the
>intersection of two non-overlapping ranges.

I fully agree with this. Such "pinned to a location" empty range
is exactly what I needed for regexp_positions() and is what
the patch implements.

It seems that the consequences of allowing empty ranges with bounds information
wasn't really discussed in detail in this thread. Nobody commented on Kevin's idea, as far as I can see when reading the thread.

Instead, the discussion focused on the consequences of
allowing empty ranges without bounds information,
which apparently was finally accepted, since that's what we have now.

/Joel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Jacobson 2021-03-02 19:20:59 Re: [PATCH] Support empty ranges with bounds information
Previous Message Mark Dilger 2021-03-02 19:02:10 Re: [PATCH] Support empty ranges with bounds information