(2010/11/29 10:43), Robert Haas wrote:
> 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.
>
I thought the author concerned about inconsistency between them.
(Perhaps, I might misunderstood his motivation?)
What was the purpose that this patch tries to solve?
In the first message of this topic, he concerned as follows:
> I noticed that granting a user column-level update privileges doesn't
> allow that user to issue LOCK TABLE with any mode other than Access
> Share.
Do we need to answer: "Yes, it is a specification, so you need to grant
table level privileges, instead"?
Thanks
--
KaiGai Kohei <kaigai@ak.jp.nec.com>