2010/11/28 KaiGai Kohei <kaigai@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