I wrote:
> Tomas Vondra <tomas.von...@2ndquadrant.com> writes:
>> I do recall a discussion about executing expressions on index tuples
>> during IOS (before/without inspecting the heap tuple). I'm too lazy to
>> search for the thread now, but I recall it was somehow related to
>> leak-proof-ness. And AFAICS none of the "div" procs are marked as
>> leak-proof, so perhaps that's one of the reasons?
> Leak-proof-ness is kind of related, perhaps, but it's not quite the property
> we're after here --- at least not to my mind. It might be an interesting
> discussion exactly what the relationship is. Meanwhile, we don't have any
> separate concept of functions that are safe to apply to any index entry;
> opclass membership is it.
The other thread about RLS helped me to crystallize the vague feelings
I had about this. I now think that this is what we're actually assuming:
an indexable operator must be leakproof *with respect to its index-key
input*. If it is not, it might throw errors or otherwise reveal the
existence of index entries for dead rows, which would be a usability fail
whether or not you are excited about security as such.
On the other hand, it's okay to throw errors that only reveal information
about the non-index input. For instance, it's not a problem for pg_trgm
to treat regex-match operators as indexable, even though those will throw
error for a malformed pattern input.
So this is indeed related to leakproof-ness, but our current definition
of "leakproof" is too simple to capture the property exactly.
Getting back to the question of this thread, I think we'd have to restrict
any filtering done in advance of heap liveness checks to fully leakproof
functions, since we don't want the filter expression to possibly throw
an error, regardless of which input(s) came from the index.
regards, tom lane
