On Wed, 2026-07-01 at 18:33 -0400, Tom Lane wrote: > Laurenz Albe <[email protected]> writes: > > This is an attempt to get the operators from the "enum_ops" operator > > class LEAKPROOF. > > I think we should reject this idea. Our standard for marking > functions leakproof has always included a requirement that the amount > of code involved be small enough that one can immediately confirm that > there is no information leak. I don't think that enum_cmp() can meet > that standard; the length of your argument already proves the point. > The issue here is not really "can I convince myself that it's safe > today?". It's more about "am I willing to bet that no future code > change is going to unintentionally break the property?". The more > code involved, the riskier that bet.
Yes, future code changes could be a risk. However, I don't think it particularly likely that any error message added will output one of the arguments of the comparison function: all the tricky parts in that function deal with catalog lookups or memory allocation for a cache. What bothers me in general is that we hold leakproofness to a standard that borders on the paranoid (which is not necessarily wrong with security features), but the promises we make for row-level security are rather low (EXPLAIN ANALYZE subverts it) and we have rejected improvements in that area. I am worried that that makes row-level security much less useful in practice than it could and should be. > I know that you are going to say "but text_cmp covers a lot of > ground, including code (in libc or ICU) that isn't even ours". > To my mind, we made an exception for text_cmp because the performance > consequences of not making it leakproof were unacceptable. > I do not think enum_cmp() can clear that bar either. I won't dispute that "text" is more important than "enum". But enums are important enough for one of our customers that they had me look into getting enum comparisons leakproof. Andreas, do you want to comment? > FWIW, I do agree that marking enum_eq leakproof is safe. How > many of the use-cases you are worried about would be satisfied > with that? Only equality comparisons are important, but in [1] you made the argument that something could substitute enum_cmp() for enum_eq(), so I thought it would be necessary to get both leakproof. Yours, Laurenz Albe [1]: https://postgr.es/m/641899.1750095380%40sss.pgh.pa.us
