On Fri, Jul 9, 2010 at 10:51 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > The loadable module doesn't "gain control" here it simplify kicks-in > after, and in addition to, normal checking. That just means you have the > option of failing for additional reasons.
True. We could change it so that the normal checking is bypassed if the hook is installed, and leave it up to the hook whether to call the standard checks as well, but I don't think there's much of a use case for that. > We're not passing in any form of context other than the rangetable so > what additional reasons could there be? This is of no use to anything > that uses object labelling. We're not even at the part of the executor > where we would be able to identify objects yet, so I can't see what > value this brings. Though I am certainly in favour in general terms of > simple changes to enhance security configuration features. Well, KaiGai Kohei already posted a proof-of-concept patch showing how this could be used by a simple SE-PostgreSQL implementation. Since we don't have a security labelling facility yet, he used the comment on the relation to store the security label (there are other ways it could be done too, of course). > Strangely, I was looking into removing the ExecCheckRTPerms check > altogether by forcing plan invalidation when permissions are updated. > That would be a performance tweak that would render this change useless. Huh. Obviously, I would have refrained from committing the patch had I known that it was going to conflict with work someone else was doing in this area, at least until we reached consensus on which way to go with it, but since you didn't post about it on -hackers, I had no idea that was the case. Sounds like you should probably post your proposal and we can discuss what to do in general and also with respect to this hook. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
