Re: [PATCH] Support empty ranges with bounds information

> On Mar 2, 2021, at 9:52 AM, Joel Jacobson <joel(at)compiler(dot)org> wrote:
>
> On Tue, Mar 2, 2021, at 15:42, Tom Lane wrote:
>> "Joel Jacobson" <joel(at)compiler(dot)org> writes:
>> > As discussed in the separate thread "[PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]" [1]
>> > 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().
>>
>> I think this is an actively bad idea. We had a clean set-theoretic
>> definition of ranges as sets of points, and with this we would not.
>> We should not be whacking around the fundamental semantics of a
>> whole class of data types on the basis that it'd be cute to make
>> regexp_position return its result as int4range rather than int[].
>
> I think there are *lots* of other use-cases where the current semantics of range types are very problematic.

I'm inclined to think that this conversation is ten years too late. Range semantics are already relied upon in our code, but also in the code of others. It might be very hard to debug code that was correct when written but broken by this proposed change. The problem is not just with lower() and upper(), but with equality testing (mentioned upthread), since code may rely on two different "positions" (your word) both being equal, and both sorting the same.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company