| From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
|---|---|
| To: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Joel Jacobson <joel(at)compiler(dot)org> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com> |
| Subject: | Re: [PATCH] Support empty ranges with bounds information |
| Date: | 2021-03-02 18:16:03 |
| Message-ID: | 603E80E3.6050606@anastigmatix.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
Regards,
-Chap
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Dilger | 2021-03-02 18:17:10 | Re: [PATCH] Support empty ranges with bounds information |
| Previous Message | Bruce Momjian | 2021-03-02 18:12:51 | Re: GiST comment improvement |