On Tue, Mar 19, 2013 at 9:28 AM, Kohei KaiGai wrote:
>> But I've left it the way you have it for now. Part
>> of me thinks that what you really want here is a pre-alter hook rather
>> than a post-alter hook...
>>
> Yes. It is the reason why I wanted to put a pre-alter hook for this
> code path e
On Tue, Mar 12, 2013 at 11:53 AM, Kohei KaiGai wrote:
> The attached patch is rebased one towards the latest master.
> It newly added a hook being missed in the previous revision at ALTER
> EVENT TRIGGER ENABLE / DISABLE, and adjusted argument of
> finish_heap_swap() on REFRESH MATERIALIZED VIEW t
Thanks for your reviewing.
2013/3/7 Robert Haas :
> On Sun, Jan 27, 2013 at 1:55 AM, Kohei KaiGai wrote:
>> The part-2 patch adds new OAT_POST_ALTER event type, and
>> its relevant permission checks on contrib/sepgsql.
>
> This documentation hunk is unclear:
>
> +On , install permission
> +
On Sun, Jan 27, 2013 at 1:55 AM, Kohei KaiGai wrote:
> The part-2 patch adds new OAT_POST_ALTER event type, and
> its relevant permission checks on contrib/sepgsql.
This documentation hunk is unclear:
+On , install permission
+will be checked if leakproof attribute was given, not only
+
On Sun, Jan 27, 2013 at 1:55 AM, Kohei KaiGai wrote:
> The part-1 patch adds catalog/objectaccess.c to have entrypoints of
> object_access_hook, instead of simple macro definition, to simplify
> invocations with arguments. It is just a replacement of existing
> OAT_POST_CREATE and OAT_DROP invocat
2012/12/11 Robert Haas :
> On Mon, Dec 3, 2012 at 9:59 AM, Kohei KaiGai wrote:
>> As we discussed before, it is hard to determine which attributes shall
>> be informed to extension via object_access_hook, so the proposed
>> post-alter hook (that allows to compare older and newer versions)
>> works
On Mon, Dec 3, 2012 at 9:59 AM, Kohei KaiGai wrote:
> As we discussed before, it is hard to determine which attributes shall
> be informed to extension via object_access_hook, so the proposed
> post-alter hook (that allows to compare older and newer versions)
> works fine on 99% cases.
> However,
2012/12/3 Robert Haas :
> On Sat, Dec 1, 2012 at 2:57 AM, Kohei KaiGai wrote:
>> * Do we need OAT_POST_ALTER hook even if no fields were updated
>> actually? In case when ALTER SET OWNER, it checks object's ownership
>> only when current and new user-id is not same. Right now, I follow this
>>
2012/12/3 Robert Haas :
> On Tue, Nov 20, 2012 at 8:43 AM, Kohei KaiGai wrote:
>> I'd like to have catalog/objectaccess.c to wrap-up invocation of hooks,
>> rather
>> than doing all the stuffs with macros. It allows to use local variables,
>> unlike
>> macros; that has a risk of naming conflict
On Sat, Dec 1, 2012 at 2:57 AM, Kohei KaiGai wrote:
> * Do we need OAT_POST_ALTER hook even if no fields were updated
> actually? In case when ALTER SET OWNER, it checks object's ownership
> only when current and new user-id is not same. Right now, I follow this
> manner on OAT_POST_ALTER in
On Tue, Nov 20, 2012 at 8:43 AM, Kohei KaiGai wrote:
> I'd like to have catalog/objectaccess.c to wrap-up invocation of hooks, rather
> than doing all the stuffs with macros. It allows to use local variables,
> unlike
> macros; that has a risk of naming conflict with temporary variable for
> Obje
>> The second hunk to alter.c does not apply anymore; please rebase.
>>
> OK,
Oops, I assumed the patch for ALTER RENAME TO reworks. Sorry.
2012/11/20 Alvaro Herrera :
> Kohei KaiGai wrote:
>
>> I'd like to have catalog/objectaccess.c to wrap-up invocation of hooks,
>> rather
>> than doing all t
Kohei KaiGai wrote:
> I'd like to have catalog/objectaccess.c to wrap-up invocation of hooks, rather
> than doing all the stuffs with macros. It allows to use local variables,
> unlike
> macros; that has a risk of naming conflict with temporary variable for
> ObjectAccessPostCreate.
No objection
2012/11/19 Alvaro Herrera :
> Kohei KaiGai wrote:
>> Sorry, I missed the attached version.
>> Please use this revision.
>
> All those direct uses of object_access_hook make me think that the
> InvokeObjectAccessHook() macro we have is insufficient. Maybe we could
> have InvokeObjectAccessHookArg1(
Kohei KaiGai wrote:
> Sorry, I missed the attached version.
> Please use this revision.
All those direct uses of object_access_hook make me think that the
InvokeObjectAccessHook() macro we have is insufficient. Maybe we could
have InvokeObjectAccessHookArg1() so that instead of
+ if (object_ac
15 matches
Mail list logo
