Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
Date: 2009-04-17 05:27:22
Message-ID: 49E8133A.7090601@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

KaiGai Kohei wrote:
> 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 */
> #define ACL_SELECT_FOR_UPDATE ACL_UPDATE
> :
>
> 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.

What's the point of doing SELECT FOR UPDATE if you're not actually going
to UPDATE the row? Having separate permissions for SELECT FOR UPDATE and
UPDATE seems useless.

A separate permission for SELECT FOR SHARE makes more sense, though.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2009-04-17 06:16:01 Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
Previous Message Tom Lane 2009-04-17 05:08:58 Re: Lifetime of FmgrInfo