On Mon, Oct 11, 2010 at 9:58 PM, KaiGai Kohei <kaigai@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