On 2018-10-01 11:58:51 -0400, Tom Lane wrote:
> Mark Wong <mark@2ndQuadrant.com> writes:
> > a | a | uuid_cmp
> > --------------------------------------+--------------------------------------+-------------
> > 11111111-1111-1111-1111-111111111111 | 11111111-1111-1111-1111-111111111111 | 0
> > 11111111-1111-1111-1111-111111111111 | 22222222-2222-2222-2222-222222222222 | -2147483648
> > 11111111-1111-1111-1111-111111111111 | 3f3e3c3b-3a30-3938-3736-353433a2313e | -2147483648
> > 22222222-2222-2222-2222-222222222222 | 11111111-1111-1111-1111-111111111111 | 1
> > 22222222-2222-2222-2222-222222222222 | 22222222-2222-2222-2222-222222222222 | 0
> > 22222222-2222-2222-2222-222222222222 | 3f3e3c3b-3a30-3938-3736-353433a2313e | -2147483648
> > 3f3e3c3b-3a30-3938-3736-353433a2313e | 11111111-1111-1111-1111-111111111111 | 1
> > 3f3e3c3b-3a30-3938-3736-353433a2313e | 22222222-2222-2222-2222-222222222222 | 1
> > 3f3e3c3b-3a30-3938-3736-353433a2313e | 3f3e3c3b-3a30-3938-3736-353433a2313e | 0
> > (9 rows)
>
>
> Oooh ... apparently, on that platform, memcmp() is willing to produce
> INT_MIN in some cases. That's not a safe value for a sort comparator
> to produce --- we explicitly say that somewhere, IIRC.
Hm, that'd be pretty painful - memcmp() isn't guaranteed to return
anything smaller. And we use memcmp in a fair number of comparators.
> I think we implement DESC by negating the comparator's result, which
> explains why only the DESC case fails.
That makes sense.
Greetings,
Andres Freund
