rest of works for security providers in v9.1

I'd like to see opinions what facilities should be developed
to the current v9.1 development cycle.

We have integrated some of facilities to support a starter-
version of SE-PostgreSQL. It allows to hook controls on DML
permission checks and assign security labels of client and
database obejcts either by-hand or automatically.

On the other hand, hooks on DDL permission checks are still
future works from now. I believe object_access_hook is applied
on various kind of DDL permission checks, but we cannot complete
to put these hooks at once, because of patch scale.

So, I plan to integrate the following four facilities only in
the last commit-fest of v9.1, although it still does not cover
comprehensive DDL accesses .

* Expand object_access_hook to deliver arguments

Some of DDL hooks will need to deliver several arguments
in addition to OID of the object being modified. For example,
a flag to show whether this deletion is cascaded, or not.
So, prototype of the object_access_hook needs to be revised.

My idea is to add two arguments: an integer variable for number
of arguments and an array variable for the additional information.
Then, macros will wrap up invocation of this hook to keep
the code simple.

* Permission checks on object-prep-creation

It was not well concluded in the previous discussion, whether
two hooks are needed, or one.
I think the idea to divide creation hooks into two phases by its
role eventually enables to reduce the burden of code management.

Now we have OAT_POST_CREATE hooks just after registration of
dependency, basically. It is a simple enough basis, and quite
natural places to assign new security labels.
However, several cases shall be exceptions of the basis, if we
try to check permissions also in the post-creation hooks,
in addition to default labeling.

For example, heap_create_with_catalog() is called from five
places, but only two needs permission checks: DefineRelation()
and OpenIntoRel().
A few cases are not obvious whether we need permission checks
in this invocation, like a code path from make_new_heap().
It defines a new pg_class entry, but the external module cannot
determine from the catalog whether is is invoked on the code
path that needs permission checks, or not.

So, I want OAT_CREATE hooks being just after existing permission
checks for the purpose of access control, not default labeling.

* Permission checks on object-deletion

The existing code put permission checks of object deletion on
command handlers like RemoveRelations(), then it invokes
functions in dependency.c to drop the specified and dependent
objects (if necessary).
I think it is straight-forward to put object-deletion hooks
next to the existing permission checks. But it is unavailable
to check cascaded objects to be removed here.
So, it seems to me findDependentObjects() should be exposed to
external modules to inform what objects shall be dropped.
Unlike old SE-PostgreSQL implementation, I don't consider it
is a good idea to put hook within dependency.c, because we need
to inform dependency.c whether this deletion is by-hand, or
something internals (such as cleanups of temporary objects).

* Permission checks on misc easy implementables

Apart from the priority of development, it seems to me that we can
hook controls at the following commands quite easy. It is an idea
to put hooks that we can implement with little impact around the
existing codes.
- GRANT/REVOKE
- COMMENT ON
- SECURITY LABEL

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>