| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
| Cc: | Joel Jacobson <joel(at)compiler(dot)org>, 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:28:01 |
| Message-ID: | 1019198.1614709681@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
> On Mar 2, 2021, at 10:08 AM, Joel Jacobson <joel(at)compiler(dot)org> wrote:
>> On Tue, Mar 2, 2021, at 19: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.
>> That's why the patch doesn't change equality.
> How does that work if I SELECT DISTINCT ON (nr) ... and then take upper(nr). It's just random which values I get?
More generally, values that are visibly different yet compare equal
are user-unfriendly in the extreme. We do have cases like that
(IEEE-float minus zero, area-based compare of some geometric types
come to mind) but they are all warts, not things to be emulated.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zhihong Yu | 2021-03-02 18:35:06 | Re: Table AM modifications to accept column projection lists |
| Previous Message | Robert Haas | 2021-03-02 18:24:03 | Re: new heapcheck contrib module |