Re: [v9.2] Fix leaky-view problem, part 2

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Noah Misch <noah(at)2ndquadrant(dot)com>, 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 07:14:41
Message-ID: CADyhKSVNTnGEWVGCXcqmupEiVj3_ZyajrtVs62RxztPKv5d+_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2011/7/9 Robert Haas <robertmhaas(at)gmail(dot)com>:
> 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.
>
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 <kaigai(at)kaigai(dot)gr(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2011-07-09 07:34:58 Re: [HACKERS] Creating temp tables inside read only transactions
Previous Message Jeff Davis 2011-07-09 07:03:17 Re: [HACKERS] Creating temp tables inside read only transactions