Thread: Rework confusing permissions for LOCK TABLE

The existing permissions for LOCK TABLE are surprising/confusing. For
instance, if you have UPDATE privileges on a table, you can lock in any
mode *except* ACCESS SHARE.

  drop table x cascade;
  drop user u1;
  create user u1;
  create table x(i int);
  grant update on x to u1;

  set session authorization u1;
  begin;
  lock table x in access exclusive mode; -- succeeds
  commit;
  begin;
  lock table x in share mode; -- succeeds
  commit;
  begin;
  lock table x in access share mode; -- fails
  commit;

I can't think of any reason for this behavior, and I didn't find an
obvious answer in the last commits to touch that (2ad36c4e44,
fa2642438f).

Patch attached to simplify it. It uses the philosophy that, if you have
permissions to lock at a given mode, you should be able to lock at
strictly less-conflicting modes as well.


--
Jeff Davis
PostgreSQL Contributor Team - AWS

On Tue, Dec 13, 2022 at 06:59:48PM -0800, Jeff Davis wrote:
> I can't think of any reason for this behavior, and I didn't find an
> obvious answer in the last commits to touch that (2ad36c4e44,
> fa2642438f).

I can't think of a reason, either.

> Patch attached to simplify it. It uses the philosophy that, if you have
> permissions to lock at a given mode, you should be able to lock at
> strictly less-conflicting modes as well.

+1.  Your patch looks reasonable to me.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

I filed a commitfest entry for this so that it doesn't get lost:

    https://commitfest.postgresql.org/41/4093

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com