On Thu, Nov 5, 2015 at 1:29 PM, Tomas Vondra
<tomas.vondra@2ndquadrant.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
