On Fri, Nov 6, 2015 at 7:11 PM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
>> I think LEAKPROOF is probably fine for this. How would the new thing
>> be different?
>
> I don't think so - AFAIK "leakproof" is about not revealing information
> about arguments, nothing more and nothing less. It does not say whether it's
> safe to evaluate on indexes, and I don't think we should extend the meaning
> in this direction.
That seems like a non-answer answer.
Clearly, if a function can leak information about it's arguments, for
example by throwing an error, we can't call it on tuples that might
not even be visible, or the behavior of the query might be change. So
any function that is not leakproof is also not safe for this purpose.
Now that doesn't rule out the possibility that the functions for which
this optimization is safe are a subset of the leakproof functions -
but offhand I don't see why that should be the case. The index tuple
is just a tuple, and the values it contains are just datums, no more
or less than in a heap tuple. There could be a reason for concern
here, but saying that it might not be "safe to evaluate on indexes"
just begs the question: WHY wouldn't that be safe?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
