From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)2ndquadrant(dot)com> |
Cc: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Kohei Kaigai <Kohei(dot)Kaigai(at)emea(dot)nec(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [v9.2] Fix leaky-view problem, part 2 |
Date: | 2011-07-09 01:42:28 |
Message-ID: | CA+TgmoZcM1xbDAFfb69wBHnQ0HnotDJ0rD7hjBEyWL-suz-yjA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 8, 2011 at 4:57 PM, Noah Misch <noah(at)2ndquadrant(dot)com> wrote:
> Note that it does not matter whether we're actually doing an index scan -- a seq
> scan with a filter using only leakproof operators is equally acceptable. What I
> had in mind was to enumerate all operators in operator classes of indexes below
> each security view. Those become the leak-free operators for that security
> view. If the operator for an OpExpr is considered leak-free by all sources of
> its operands, then we may push it down. That's purely a high-level sketch: I
> haven't considered implementation concerns in any detail. The resulting
> behavior could be surprising: adding an index may change a plan without the new
> plan actually using the index.
>
> I lean toward favoring the pg_proc flag. Functions like "texteq" will be taken
> as leakproof even if no involved table has an index on a text column. It works
> for functions that will never take a place in an operator class, like
> length(text). When a user reports a qualifier not getting pushed down, the
> answer is much more satisfying: "Run 'CREATE OR REPLACE FUNCTION
> ... I_DONT_LEAK' as a superuser." Compare to "Define an operator class that
> includes the function, if needed, and create an otherwise-useless index." The
> main disadvantage I see is the loss of policy locality. Only a superuser (or
> maybe database owner?) can create or modify declared-leakproof functions, and
> that decision applies throughout the database. However, I think the other
> advantages clearly outweigh that loss.
This strikes me as a fairly compelling refutation of Heikki's proposed approach.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-07-09 02:15:55 | Re: [v9.2] DROP Reworks Part.1 - Consolidate routines to handle DropStmt |
Previous Message | Oleg Bartunov | 2011-07-08 22:29:42 | Re: [HACKERS] blog post on ancient history |