Skip site navigation (1) Skip section navigation (2)


From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
Date: 2009-04-17 04:47:50
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
Currently, the ACL_SELECT_FOR_UPDATE privilege is defined as an alias
of ACL_UPDATE as follows:

  at src/include/nodes/parsenodes.h:
  /* Currently, SELECT ... FOR UPDATE/FOR SHARE requires UPDATE privileges */

It is unconfortable for us because SE-PostgreSQL have two individual
permissions for updates (db_table:{update}) and explicit table locks
(db_table:{lock}), but it unables to discriminate whether the given
relation is actually used for UPDATE or SELECT FOR UPDATE.
So, I would like to define the bit as (1<<12) which is not in use.

I think we have two options to solve the matter.

The one is to check ACL_SELECT_FOR_UPDATE by UPDATE privilege, as
the attached patch doing. It implicitly expands the users privilege
when he has ACL_UPDATE, so it enables GRANT UPDATE to cover both of
ACL_UPDATE and ACL_SELECT_FOR_UPDATE as the current implementation

The other is to add a new privilege for explicit table locks, such
as something like LOCK privilege. It is a straightforward approach,
but we need to have a user visible changes.

Which is more preferable design?

OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

Attachment: pgsql-v8.5-select_for_update.patch
Description: text/x-patch (3.1 KB)


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-04-17 05:08:58
Subject: Re: Lifetime of FmgrInfo
Previous:From: Joshua TolleyDate: 2009-04-17 02:49:34
Subject: Lifetime of FmgrInfo

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group