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