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
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 |