On Fri, Jul 19, 2013 at 12:33 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Stephen Frost <sfr...@snowman.net> writes: >> if (lockmode == AccessShareLock) >> aclresult = pg_class_aclcheck(reloid, GetUserId(), >> ACL_SELECT); >> + else if (lockmode == RowExclusiveLock) >> + aclresult = pg_class_aclcheck(reloid, GetUserId(), >> + ACL_INSERT | ACL_UPDATE | ACL_DELETE | >> ACL_TRUNCATE); >> else >> aclresult = pg_class_aclcheck(reloid, GetUserId(), >> ACL_UPDATE | ACL_DELETE | >> ACL_TRUNCATE); > > Perhaps it would be better to refactor with a local variable for the > aclmask and just one instance of the pg_class_aclcheck call. Also, I'm > pretty sure that the documentation work needed is more extensive > than the actual patch ;-). Otherwise, I don't see a problem with this.
I don't really care one way or the other whether we change this in master, but I think back-patching changes that loosen security restrictions is a poor idea. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
