On Fri, Nov 6, 2015 at 7:15 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > 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.
Is there a reason they aren't leak proof? I don't see that they have side effects, or that they can throw errors. What do they leak? Anyway, I just picked that for convenience. One of the original pieces that lead me on this quest had a range inclusion rather than a LIKE. I just thought that changing it to a LIKE made the data generator simpler and easier to reason about, without changing the fundamental principle. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
