2011/11/27 Dimitri Fontaine <dimitri@2ndquadrant.fr>:
> Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
>>> I wonder if you could implement that as an extension given the command
>>> trigger patch finds its way in. What do you think?
>>>
>> Unfortunately, it does not solve my point.
>
> [...]
>
>> It is also reason why I mentioned about an idea that put prep-creation hook
>> on a limited number of object classes only. It requires us code modification
>> to maintain an opaque private between prep- and post- hooks.
>
> In my current proposal for command triggers, the trigger procedure is
> given schemaname and objectname as separate arguments. It seems to me
> easy enough to use that as a key to some data structure where the value
> is any opaque data you need, and that you maintain in your extension
> triggers code. You can write them in C.
>
Sorry, it does not cover all the code paths that I want to apply permission
checks around creation of new tables.
The existing DAC checks permission on creation of new tables at
DefineRelation() and OpenIntoRel(), and sepgsql also wants to follow
this manner.
However, OpenIntoRel() does not go through ProcessUtility, so it seems
to me the command trigger is not invoked in this case.
And, it seems to me the current proposition of the command trigger
does not support to fire triggers on creation of databases, although
permission checks requires Oid of source database that is not also
appeared in pg_database catalog.
> I don't think schemaname+objectname fails to be unique, so I don't think
> you need another kind of Oid in BEFORE creation triggers here.
>
The pg_seclabel and pg_shseclabel needs OID to assign a security label
on a particular database object, so label provider (sepgsql) must know
Oid of the target object on assignment time.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>