2010/10/11 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> It enables us to put security hooks independent from MVCC visibility of
> the new database object. If we pay attention for visibility of new database
> object, it seems to me amount of things to understand and maintain will be
> increased, although MVCC visibility is fundamentally unrelated stuff from
> viewpoint of the access control.
>
> In the idea of two hooks, the prep-creation hook shall be invoked in same
> visibility of existing permission checks, and the post-creation hook shall
> be invoked in same visibility of simple_heap_* operations.
> I think it enables to reduce amount of things to understand and maintain,
> because the scope we should pay attention become small, if we can put
> security hooks independent from MVCC visibility.
>
> Perhaps, the problem may be intangible, but I don't think it is fair
> enough if we have to pay attention about MVCC visibility of plugin
> modules whenever we try to apply a patch around creation hooks.
This may be nothing more than a matter of opinion, but it seems to me
that what you're proposing makes this vastly more complicated for no
particular benefit. Instead of having one hook that can cover a wide
variety of use cases, you're going to need individual hooks for each
object type plus the ability to pass data between them. And the point
of this, apparently, is so that you can avoid using the standard
syscache functions that the entire backend uses for retrieving
information about objects and instead extract it in some other way;
and/or avoid having to deal with the MVCC properties of which the rest
of the backend must be aware. Maybe somebody else has a different
opinion, but I just can't get even a little excited about that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
