On Wed, Jul 20, 2011 at 04:23:10PM +0200, Yeb Havinga wrote:
> On 2011-07-20 16:15, Yeb Havinga wrote:
>> On 2011-07-20 16:06, Noah Misch wrote:
>>>
>>> The SQL-level semantics of the view define the access rules in
>>> question. How
>>> would you translate that into tests to apply at a lower le
On 2011-07-20 16:15, Yeb Havinga wrote:
On 2011-07-20 16:06, Noah Misch wrote:
The SQL-level semantics of the view define the access rules in
question. How
would you translate that into tests to apply at a lower level?
I assumed the leaky view thread was about row level security, not
about
On 2011-07-20 16:06, Noah Misch wrote:
The SQL-level semantics of the view define the access rules in question. How
would you translate that into tests to apply at a lower level?
I assumed the leaky view thread was about row level security, not about
access rules to views, since it was mention
On Wed, Jul 20, 2011 at 09:02:59AM +0200, Yeb Havinga wrote:
> On 2011-07-09 09:14, Kohei KaiGai wrote:
>> 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 co
2011/7/20 Yeb Havinga :
> On 2011-07-09 09:14, Kohei KaiGai wrote:
>>
>> 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 b
On 2011-07-09 09:14, Kohei KaiGai wrote:
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.
A diff
2011/7/9 Robert Haas :
> On Fri, Jul 8, 2011 at 4:57 PM, Noah Misch 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 i
On Fri, Jul 8, 2011 at 4:57 PM, Noah Misch 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
On Fri, Jul 08, 2011 at 10:09:54AM +0100, Kohei KaiGai wrote:
> 2011/7/8 Heikki Linnakangas :
> > On 08.07.2011 11:03, Kohei KaiGai wrote:
> >>
> >> 2011/7/7 Noah Misch:
> >>>
> >>> Making a distinction based simply on the call being an operator vs. a
> >>> function
> >>> is a dead end. ?I see thes
On Fri, Jul 8, 2011 at 4:18 AM, Heikki Linnakangas
wrote:
> IMHO the situation from DBA's point of view is exactly opposite. Option two
> requires deep knowledge of this leaky views issue. The DBA needs to inspect
> any function he wants to mark as leak-free closely, and understand that
> innocent
2011/7/8 Heikki Linnakangas :
> On 08.07.2011 11:03, Kohei KaiGai wrote:
>>
>> 2011/7/7 Noah Misch:
>>>
>>> Making a distinction based simply on the call being an operator vs. a
>>> function
>>> is a dead end. I see these options:
>>>
>>> 1. The user defining a security view can be assumed to trus
On 08.07.2011 11:03, Kohei KaiGai wrote:
2011/7/7 Noah Misch:
Making a distinction based simply on the call being an operator vs. a function
is a dead end. I see these options:
1. The user defining a security view can be assumed to trust the operator class
members of indexes defined on the tab
2011/7/7 Noah Misch :
> On Sun, Jul 03, 2011 at 11:41:47AM +0200, Kohei KaiGai wrote:
>> The simplified version of fix-leaky-view patch. The part of reloptions
>> for views got splitted out
>> into the part-0 patch, so it needs to be applied prior to this patch.
>> Rest of logic to prevent unexpect
On Sun, Jul 03, 2011 at 11:41:47AM +0200, Kohei KaiGai wrote:
> The simplified version of fix-leaky-view patch. The part of reloptions
> for views got splitted out
> into the part-0 patch, so it needs to be applied prior to this patch.
> Rest of logic to prevent unexpected pushing down across secur
The simplified version of fix-leaky-view patch. The part of reloptions
for views got splitted out
into the part-0 patch, so it needs to be applied prior to this patch.
Rest of logic to prevent unexpected pushing down across security
barrier is not changed.
Thanks,
2011/6/6 Kohei Kaigai :
> This p
15 matches
Mail list logo
