LOCK TABLE Permissions

Greetings,
 We've run into a curious case and I'd like to solicit feedback regarding a possible change to the access rights
requiredto acquire locks on a relation.  Specifically, we have a process which normally INSERTs into a table and
anotherprocess which Exclusive locks that same table in order to syncronize other processing.  We then ran into a case
wherewe didn't actually want to INSERT but still wanted to have the syncronization happen.  Unfortunately, we don't
allowLOCK TABLE to acquire RowExclusive unless you have UPDATE, DELETE, or TRUNCATE privileges.
 
 My first impression is that the current code was just overly simplistic regarding what level of permissions are
requiredfor a given lock type and that it wasn't intentional to deny processes which have INSERT privileges from
acquiringRowExclusive (as they can do so anyway using an actual INSERT).  Therefore, I'd like to propose the below
simple3-line patch to correct this.
 
 Thoughts?  Objections to back-patching?
     Thanks,
    Stephen

diff --git a/src/backend/commands/lockcmds.c b/src/backend/commands/lockcmds.c
new file mode 100644
index 49950d7..60f54c5 100644
*** a/src/backend/commands/lockcmds.c
--- b/src/backend/commands/lockcmds.c
*************** LockTableAclCheck(Oid reloid, LOCKMODE l
*** 174,179 ****
--- 174,182 ----   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);