Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
Дата
Msg-id 49E8133A.7090601@enterprisedb.com
обсуждение исходный текст
Ответ на [PATCH] unalias of ACL_SELECT_FOR_UPDATE  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Ответы Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Lifetime of FmgrInfo
Следующее
От: KaiGai Kohei
Дата:
Сообщение: Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE