2010/11/28 KaiGai Kohei <kai...@ak.jp.nec.com>: >> I'm not totally convinced that this is the correct behavior. It seems >> a bit surprising that UPDATE privilege on a single column is enough to >> lock out all SELECT activity from the table. It's actually a bit >> surprising that even full-table UPDATE privileges are enough to do >> this, but this change would allow people to block access to data they >> can neither see nor modify. That seems counterintuitive, if not a >> security hole. >> > In my understanding, UPDATE privilege on a single column also allows > lock out concurrent updating even if this query tries to update rows > partially. > Therefore, the current code considers UPDATE privilege on a single > column is enough to lock out the table. Right?
Against concurrent updates and deletes, yes. Against inserts that don't involve potential unique-index conflicts, and against selects, no. > My comment was from a standpoint which wants consistent behavior > between SELECT ... FOR and LOCK command. Again, nothing about this makes those consistent. > If we concerned about this > behavior, ExecCheckRTEPerms() might be a place where we also should fix. I don't understand what you're getting at here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
