On Mon, Oct 11, 2010 at 9:58 PM, KaiGai Kohei <kai...@ak.jp.nec.com> wrote: > It seems to me the conclusion of this discussion is unclear. > > We commonly try to find out an approach that minimize code complexity > to understand and maintain, so the point of issue is clear, but we > still don't reach same conclusion, because both of two ideas have merits > and demerits each other. > > * Prep/Post-creation hook > merits: simple principle to deploy security hooks. The prep-creation > hook shall be after existing DAC checks, and the post-creation hook > shall be after modification of system catalogs. > demerits: several specific security hooks are necessary, in addition > to the main security hook. > > * Only post-creation hook > merits: small number of security hook definitions. > demerits: at least, new entries of system catalog must be visible > when we invoke the security hooks, so some cases require us to > add new CCIs on invocations, but it requires us to verify it is > harmless (whenever we will touch the code around security hooks > in the future). > > In my viewpoint, MVCC is one of the most complex things in PG. > So, in fact, I also missed the possibility that the gust of security > hook cannot reference the entry of new database object, when the idea > of post-creation hook was suggested. > If we have a strong (and implicit) restriction about places where > we should deploy the security hooks on, I don't think it enables to > minimize our task to understand and maintain (in the future), although > line of change set is a bit smaller now. > > So, I think the idea of two hooks on creation is better. > It tries to put prep-creation hook according to the manner of existing > DAC checks, and post-creation hook is next to modification of system > catalogs with same visibility of the main entries. > It seems to me this simple principle enables to minimize our task to > understand and maintain.
I don't understand what problem you think having two hooks will solve. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
