Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
Date
Msg-id 49E8133A.7090601@enterprisedb.com
Whole thread Raw
In response to [PATCH] unalias of ACL_SELECT_FOR_UPDATE  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
List 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Lifetime of FmgrInfo
Next
From: KaiGai Kohei
Date:
Subject: Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE