I wrote: > I propose to run through the system operator classes, find any for which > the comparison function isn't marked leakproof but the operators are, > and fix them. This is clearly appropriate for HEAD and maybe it's not > too late to force an initdb for v11 --- thoughts?
I did that for the built-in btree opclasses. I decided that it's probably not worth forcing an initdb in v11 for, though. In principle, losing selectivity estimates because of non-leakproof functions should only happen in queries that are going to fail at runtime anyway. The real problem that ought to be addressed and perhaps back-patched is this: > Another question that could be raised is why we are refusing to use > stats for a child table when the caller has select on the parent. > It's completely trivial to extract data from a child table if you > have select on the parent, so it seems like we are checking the > wrong table's privileges. regards, tom lane