Hi,
On 11/07/2015 02:18 AM, Robert Haas wrote:
On Fri, Nov 6, 2015 at 7:11 PM, Tomas Vondra
<tomas.von...@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.
I'm not claiming I have an answer, really. My knowledge of leakproof
stuff is a bit shallow. Also, I had a few beers earlier today, which
does not really improve the depth of knowledge on any topic except
politics and football (aka soccer). So you may be perfectly right.
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?
Ah. For some reason I thought the "division by zero" example is one of
the non-safe cases, but now I see int4div is not marked as leakproof, so
we couldn't push it to index anyway.
I've however also noticed that all the 'like' procedures are marked as
not leak proof, which is a bit unfortunate because that's the example
from Jeff's e-mail that started this thread.
regards
--
Tomas Vondra http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
