KaiGai Kohei wrote:
> We have an another approach that defines ACL_SELECT_FOR_SHARE as
> an alias of ACL_SELECT, and applies it on SELECT FOR SHARE statement.
> (Needless to say, the targets are already listed, so it might not necessary
> to put a ACL_SELECT_FOR_SHARE bit explicitly.)
That's even more useless, since you need ACL_SELECT for SELECT FOR SHARE
anyway.
> In the LOCK statement, it checks ACL_SELECT privilege for shared locks and
> discriminate between shared and exclusive locks. It seems to me quite natural.
It checks ACL_SELECT for *Access*ShareLock. SELECT FOR SHARE acquires a
RowShareLock. So the equivalent of "SELECT * FROM foo FOR SHARE" using
LOCK is "LOCK TABLE foo RowShareLock", which checks
ACL_UPDATE|ACL_DELETE|ACL_TRUNCATE.
IMHO the only sane change would be to introduce a new
ACL_SELECT_FOR_SHARE permission for SELECT FOR SHARE. That way you could
grant SELECT_FOR_SHARE permission on a table to let people insert rows
into other tables that have a foreign key reference to it, without
having to grant UPDATE permission.
Does the SQL spec have anything to say about this, BTW?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
