On Thu, Nov 5, 2015 at 1:29 PM, Tomas Vondra <tomas.von...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
