On Fri, Mar 9, 2012 at 2:41 PM, Robert Haas wrote:
> On Sat, Feb 4, 2012 at 10:54 AM, Kohei KaiGai wrote:
>> OK, I modified the patch according to your suggestions.
>>
>> object_access_hook was extended to take an argument of void * pointer,
>> and InvokeObjectAccessHook was also allows to delive
On Sat, Feb 4, 2012 at 10:54 AM, Kohei KaiGai wrote:
> OK, I modified the patch according to your suggestions.
>
> object_access_hook was extended to take an argument of void * pointer,
> and InvokeObjectAccessHook was also allows to deliver it.
Sorry for the long radio silence on this patch. Th
On Sat, Jan 28, 2012 at 1:53 PM, Kohei KaiGai wrote:
> 2012/1/26 Robert Haas :
>> On Thu, Jan 26, 2012 at 7:27 AM, Kohei KaiGai wrote:
>>> It seems to me reasonable design.
>>> The attached patch is rebased one according to your perform-deletion patch.
>>
>> That looks pretty sensible. But I don
2012/1/26 Robert Haas :
> On Thu, Jan 26, 2012 at 7:27 AM, Kohei KaiGai wrote:
>> It seems to me reasonable design.
>> The attached patch is rebased one according to your perform-deletion patch.
>
> That looks pretty sensible. But I don't think this is true any more:
>
> + Please note that it
On Thu, Jan 26, 2012 at 7:27 AM, Kohei KaiGai wrote:
> It seems to me reasonable design.
> The attached patch is rebased one according to your perform-deletion patch.
That looks pretty sensible. But I don't think this is true any more:
+Please note that it shall not be checked on the object
On Sun, Jan 22, 2012 at 9:54 AM, Kohei KaiGai wrote:
> I tried to implement based on the idea to call object-access-hook with
> flag; that
> informs extensions contexts of objects being removed.
> Because I missed DROP_RESTRICT and DROP_CASCADE are enum type,
> this patch added performInternalDele
2012/1/19 Robert Haas :
> On Thu, Jan 19, 2012 at 3:51 AM, Kohei KaiGai wrote:
>> 2012/1/19 Robert Haas :
>>> On Wed, Jan 18, 2012 at 9:50 AM, Kohei KaiGai wrote:
In sepgsql side, it determines a case to apply permission checks
according to the contextual information; that is same techn
On Thu, Jan 19, 2012 at 3:51 AM, Kohei KaiGai wrote:
> 2012/1/19 Robert Haas :
>> On Wed, Jan 18, 2012 at 9:50 AM, Kohei KaiGai wrote:
>>> In sepgsql side, it determines a case to apply permission checks
>>> according to the contextual information; that is same technique
>>> when we implemented c
2012/1/19 Robert Haas :
> On Wed, Jan 18, 2012 at 9:50 AM, Kohei KaiGai wrote:
>> In sepgsql side, it determines a case to apply permission checks
>> according to the contextual information; that is same technique
>> when we implemented create permission.
>> Thus, it could checks db_xxx:{drop} per
On Wed, Jan 18, 2012 at 9:50 AM, Kohei KaiGai wrote:
> In sepgsql side, it determines a case to apply permission checks
> according to the contextual information; that is same technique
> when we implemented create permission.
> Thus, it could checks db_xxx:{drop} permission correctly.
Why do we
On Tue, Jan 17, 2012 at 10:55 AM, Kohei KaiGai wrote:
> Do I modify the patch to place object-access-hook on deleteOneObject
> (probably, it is the best position to track actual deletion)?
> One problem is case of deletion of columns by ALTER TABLE.
> It just marks "attisdropped" flag; without rem
2012/1/17 Robert Haas :
> On Tue, Jan 10, 2012 at 7:51 AM, Kohei KaiGai wrote:
>> The attached patch adds OAT_DROP object-access-hook around permission
>> checks of object deletion.
>> Due to the previous drop statement reworks, the number of places to
>> put this hook is limited to these six poin
On Tue, Jan 10, 2012 at 7:51 AM, Kohei KaiGai wrote:
> The attached patch adds OAT_DROP object-access-hook around permission
> checks of object deletion.
> Due to the previous drop statement reworks, the number of places to
> put this hook is limited to these six points: RemoveObjects,
> RemoveRel
13 matches
Mail list logo
