Pierre Ducroquet <p.p...@pinaraf.info> writes: > For simple functions like enum_eq/enum_ne, marking them leakproof is an > obvious fix (patch attached to this email, including also textin/textout).
This is not nearly as "obvious" as you think. See prior discussions, notably https://www.postgresql.org/message-id/flat/31042.1546194242%40sss.pgh.pa.us Up to now we've taken a very strict definition of what leakproofness means; as Noah stated, if a function can throw errors for some inputs, it's not considered leakproof, even if those inputs should never be encountered in practice. Most of the things we've been willing to mark leakproof are straight-line code that demonstrably can't throw any errors at all. The previous thread seemed to have consensus that the hazards in text_cmp and friends were narrow enough that nobody had a practical problem with marking them leakproof --- but we couldn't define an objective policy statement that would allow making such decisions, so nothing's been changed as yet. I think it is important to have an articulable policy about this, not just a seat-of-the-pants conclusion about the risk level in a particular function. regards, tom lane
