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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
