Re: security hooks on object creation

The attached patch is a revised patch.

- The utils/hooks.h was renamed to catalog/objectaccess.h
- Numeric in the tail of InvokeObjectAccessHook0() has gone.
- Fixed bug in ATExecAddColumn; it gave AttributeRelationId
  to the hook instead of RelationRelationId.

In addition, I found that we didn't put post-creation hook
on foreign data wrapper, foreign server and user mapping
exceptionally. So, I put this hook around their command
handler like any other object classes.

Thanks,

(2010/11/24 12:07), Robert Haas wrote:
> 2010/11/23 KaiGai Kohei<kaigai@ak.jp.nec.com>:
>>> What
>>> I'm not quite sure about is where to put the definitions you've added
>>> to a new file utils/hooks.h; I don't feel that's a very appropriate
>>> location.  It's tempting to put them in utils/acl.h just because this
>>> is vaguely access-control related and that header is already included
>>> in most of the right places, but maybe that's too much of a stretch;
>>> or perhaps catalog/catalog.h, although that doesn't feel quite right
>>> either.  If we are going to add a new header file, I still don't like
>>> utils/hooks.h much - it's considerably more generic than can be
>>> justified by its contents.
>>>
>> I don't think utils/acl.h is long-standing right place, because we
>> intended not to restrict the purpose of this hooks to access controls
>> as you mentioned.
>>
>> I think somewhere under the catalog/ directory is a good idea because
>> it hooks events that user wants (eventually) to modify system catalogs.
>> How about catalog/hooks.h, instead of utils/hooks.h?
>
> Well, if we're going to create a new header file for this, I think it
> should be called something like catalog/objectaccess.h, rather than
> just hooks.h.  But I'd rather reuse something that's already there,
> all things being equal.
>


--
KaiGai Kohei <kaigai@ak.jp.nec.com>