Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 7BD47632A20 for ; Fri, 17 Apr 2009 02:27:33 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 59774-01 for ; Fri, 17 Apr 2009 02:27:31 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by mail.postgresql.org (Postfix) with SMTP id 4F24763254D for ; Fri, 17 Apr 2009 02:27:26 -0300 (ADT) Received: from source ([74.125.78.27]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSegTPU6y+8shkJw3XdgxtfydOa8RhRT/@postini.com; Thu, 16 Apr 2009 22:27:27 PDT Received: by ey-out-2122.google.com with SMTP id 9so144912eyd.33 for ; Thu, 16 Apr 2009 22:27:24 -0700 (PDT) Received: by 10.210.127.13 with SMTP id z13mr2324958ebc.57.1239946044890; Thu, 16 Apr 2009 22:27:24 -0700 (PDT) Received: from ?80.223.212.7? (dsl-hkibrasgw2-fed4df00-7.dhcp.inet.fi [80.223.212.7]) by mx.google.com with ESMTPS id 28sm2981351eye.24.2009.04.16.22.27.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Apr 2009 22:27:24 -0700 (PDT) Message-ID: <49E8133A.7090601@enterprisedb.com> Date: Fri, 17 Apr 2009 08:27:22 +0300 From: Heikki Linnakangas Organization: EnterpriseDB User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: KaiGai Kohei CC: pgsql-hackers@postgresql.org Subject: Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE References: <49E809F6.8070008@ak.jp.nec.com> In-Reply-To: <49E809F6.8070008@ak.jp.nec.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200904/921 X-Sequence-Number: 137024 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