Mark Dilger <mark.dil...@enterprisedb.com> writes:
> On Mar 2, 2021, at 10:08 AM, Joel Jacobson <j...@compiler.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
