>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>> bttextcmp() and other varstr_cmp() callers fall afoul of the same
>> restriction with their "could not convert string to UTF-16" errors
>> (https://postgr.es/m/CADyhKSXPwrUv%2B9LtqPAQ_gyZTv4hYbr2KwqBxcs6a3Vee1jBLQ%40mail.gmail.com).
>> Leaking the binary fact that an unspecified string contains an
>> unspecified rare Unicode character is not a serious leak, however.
>> Also, those errors would be a substantial usability impediment if
>> they happened much in practice; you couldn't index affected values.
Tom> Yeah. I think that there might be a usability argument for marking
Tom> textcmp and related operators as leakproof despite this
Tom> theoretical leak condition, because not marking them puts a large
Tom> practical constraint on what conditions we can optimize. However,
Tom> that discussion just applies narrowly to the string data types; it
Tom> is independent of what we want to say the general policy is.
I think that's not even a theoretical leak; the documentation for
MultiByteToWideChar does not indicate any way in which it can return an
error for the specific parameters we pass to it. In particular we do not
tell it to return errors for invalid input characters.
--
Andrew (irc:RhodiumToad)