Re: Bitmap index scans use of filters on available columns

On Thu, Nov 5, 2015 at 1:29 PM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>> Well, one thing is that you might leak information about
>> already-deleted rows, which could be a security vulnerability, or more
>> mundanely cause a function to error out when there are no actually
>> visible rows that could trigger such an error. It would be surprising
>> if you could add a CHECK(b != 0) constraint to a table, query it for
>> rows where a/b>1, and get a division by zero error.
>
> Yes, I guess we don't have this problem when evaluating the expression on
> heap because we get to check visibility first, and after moving the
> expression to the index we can't do that.

Right.

> But then again, can we come up with a way to distinguish operators that are
> safe to evaluate on indexes - either automatic or manual? We already do that
> with the indexable operators with explicitly listing them in the opclass,
> and we also explicitly use the LEAKPROOF for a similar thing. I don't think
> extending the opclass is a really good solution, but why not to invent
> another *PROOF flag?

I think LEAKPROOF is probably fine for this. How would the new thing
be different?

> But that is about heap, and we're discussing indexes here, right? I don't
> think you can break the index descriptor like this, because otherwise we'd
> already have problems with that.

Oh, right.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company