2011/11/27 Dimitri Fontaine <dimi...@2ndquadrant.fr>: > Kohei KaiGai <kai...@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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
