Re: [GENERAL] column-level update privs + lock table

2010/11/28 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)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