Re: [PATCH] Support empty ranges with bounds information

On Tue, Mar 2, 2021, at 19:16, Chapman Flack 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?

This is actually how it's implemented. The patch doesn't affect equality.
It just stores the lower/upper bounds, if available, upon creation.

>
> 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?

This is a great idea!

This would solve the potential problems of users relying
on upper()/lower() to always return null when range isempty().

Such new functions could then be used by new users who have read the documentation
and understand how they work.
This would effectively mean there would be absolutely no semantic changes at all.

I will work on a new patch to try out this idea.

/Joel