Horton

Thread

Commits

  1. Simplify permissions for LOCK TABLE.

  1. Rework confusing permissions for LOCK TABLE

    Jeff Davis <pgsql@j-davis.com> — 2022-12-14T02:59:48Z

    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

  2. Re: Rework confusing permissions for LOCK TABLE

    Nathan Bossart <nathandbossart@gmail.com> — 2022-12-14T17:23:15Z

    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

  3. Re: Rework confusing permissions for LOCK TABLE

    Nathan Bossart <nathandbossart@gmail.com> — 2022-12-30T18:51:43Z

    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