Re: Row Level Security − leakproof-ness and performance implications

Pierre Ducroquet <p(dot)psql(at)pinaraf(dot)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