2011/7/9 Robert Haas <robertmh...@gmail.com>: > On Fri, Jul 8, 2011 at 4:57 PM, Noah Misch <n...@2ndquadrant.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. > OK, I'll try to modify the patch according to the flag of pg_proc design. As long as the default of user-defined function is off, and we provide built-in functions with appropriate configurations, it seems to me the burden of DBA is quite limited.
Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
