Currently, texteq() and textne() are marked leakproof, while
sibling operations such as textlt() are not. The argument
for that was that those two functions depend only on memcmp()
so they can be seen to be safe, whereas it's a whole lot less
clear that text_cmp() should be considered leakproof.
Of course, the addition of nondeterministic collations has
utterly obliterated that argument: it's now possible for
texteq() to call text_cmp(), so if the latter is leaky then
the former certainly must be considered so as well.
Seems like we have two choices:
1. Remove the leakproof marking on texteq()/textne(). This
would, unfortunately, be catastrophic for performance in
a lot of scenarios where leakproofness matters.
2. Fix text_cmp to actually be leakproof, whereupon we might
as well mark all the remaining btree comparison operators
leakproof.
I think #2 is pretty obviously the superior answer, if we
can do it.
ISTM we can't ship v12 without dealing with this one way
or the other, so I'll go add an open item.
Comments?
regards, tom lane
