Re: [PATCH] Support empty ranges with bounds information

> On Mar 2, 2021, at 10:16 AM, Chapman Flack <chap(at)anastigmatix(dot)net> wrote:
>
> On 03/02/21 13:01, Mark Dilger wrote:
>> 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.
>
> Could those concerns be addressed perhaps, not by adding an entirely new
> just-like-a-range-but-remembers-position-when-zero-width type (which would
> feel wartlike to me), but by tweaking ranges to /secretly/ remember the
> position when zero width?
>
> Secretly, in the sense that upper(), lower(), and the default sort
> operator would keep their established behavior, but new functions like
> upper_or_pos(), lower_or_pos() would return the non-NULL value even for
> an empty range, and another sort operator could be provided for use
> when one wants the ordering to reflect it?

I vaguely recall that ten years ago I wanted zero-width range types to not collapse into an empty range. I can't recall if I ever expressed that opinion -- I just remember thinking it would be nice, and for reasons similar to what Joel is arguing here. But I can't see having compares-equal-but-not-truly-equal ranges as a good idea. I think Tom is right about that.

I also think the regexp work that inspired this thread could return something other than a range, so the motivation for creating a frankenstein range implementation doesn't really exist.

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