Re: [v9.2] sepgsql's DROP Permission checks

2012/1/25 Robert Haas <robertmhaas@gmail.com>:
> On Sun, Jan 22, 2012 at 9:54 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> 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 performInternalDeletion() instead of OR-masked DROP_INTERNAL.
>> All its difference from performDeletion() is a flag (OAT_DROP_FLAGS_INTERNAL)
>> shall be delivered to extension module. I replaced several performDeletion() by
>> performInternalDeletion() that clean-up objects due to internal stuff.
>>
>> How about this approach?
>
> I generally agree with this line of attack, but I think you've failed
> to find all the cases where a drop should be considered internal, and
> I'd rather add a new parameter to an existing function than define a
> new one that someone might accidentally fail to use in some place
> where it's needed.  Here's a cut-down patch that *just* adds a
> PERFORM_DELETE_INTERNAL flag, plus some related comment additions.  If
> this looks reasonable to you, I'll commit it and then we can work out
> the remaining details.
>
> Since sepgsql doesn't seem to need the DropBehavior, I'm inclined to
> say we shouldn't go to any extra work to pass it just now.  We can
> always add that later if some other client needs it.
>
It seems to me reasonable design.
The attached patch is rebased one according to your perform-deletion patch.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>