From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: KaiGai Kohei <kaigai@kaigai.gr.jp>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: KaiGai Kohei <kaigai@ak.jp.nec.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
Date: Sat, 18 Apr 2009 09:35:25 +0300
Message-ID: <49E974AD.3020602@enterprisedb.com> (raw)
In-Reply-To: <49E91AE4.9020404@kaigai.gr.jp>
References: <49E809F6.8070008@ak.jp.nec.com>
<49E8133A.7090601@enterprisedb.com>
<49E81EA1.2060202@ak.jp.nec.com>
<20069.1239977115@sss.pgh.pa.us>
<49E91AE4.9020404@kaigai.gr.jp>
KaiGai Kohei wrote:
> We have an another approach that defines ACL_SELECT_FOR_SHARE as
> an alias of ACL_SELECT, and applies it on SELECT FOR SHARE statement.
> (Needless to say, the targets are already listed, so it might not necessary
> to put a ACL_SELECT_FOR_SHARE bit explicitly.)
That's even more useless, since you need ACL_SELECT for SELECT FOR SHARE
anyway.
> In the LOCK statement, it checks ACL_SELECT privilege for shared locks and
> discriminate between shared and exclusive locks. It seems to me quite natural.
It checks ACL_SELECT for *Access*ShareLock. SELECT FOR SHARE acquires a
RowShareLock. So the equivalent of "SELECT * FROM foo FOR SHARE" using
LOCK is "LOCK TABLE foo RowShareLock", which checks
ACL_UPDATE|ACL_DELETE|ACL_TRUNCATE.
IMHO the only sane change would be to introduce a new
ACL_SELECT_FOR_SHARE permission for SELECT FOR SHARE. That way you could
grant SELECT_FOR_SHARE permission on a table to let people insert rows
into other tables that have a foreign key reference to it, without
having to grant UPDATE permission.
Does the SQL spec have anything to say about this, BTW?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: heikki.linnakangas@enterprisedb.com, kaigai@kaigai.gr.jp, tgl@sss.pgh.pa.us, kaigai@ak.jp.nec.com
Subject: Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
In-Reply-To: <49E974AD.3020602@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox