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

(2010/10/16 4:49), Josh Kupershmidt wrote:
> [Moving to -hackers]
>
> On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs<simon(at)2ndquadrant(dot)com> wrote:
>> On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote:
>>> On Thu, Oct 7, 2010 at 7:43 PM, Josh Kupershmidt<schmiddy(at)gmail(dot)com> wrote:
>>>
>>>> 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.
>>>
>>> Anyone think this could be added as a TODO?
>>
>> Seems so to me, but you raise on Hackers.
>
> Thanks, Simon. Attached is a simple patch to let column-level UPDATE
> privileges allow a user to LOCK TABLE in a mode higher than Access
> Share. Small doc. update and regression test update are included as
> well. Feedback is welcome.
>

I checked your patch, then I'd like to mark it as "ready for committer".

The point of this patch is trying to solve an incompatible behavior
between SELECT ... FOR SHARE/UPDATE and LOCK command.

On ExecCheckRTEPerms(), it allows the required accesses when no columns
are explicitly specified in the query and the current user has necessary
privilege on one of columns within the target relation.
If we stand on the perspective that LOCK command should take same
privileges with the case when we use SELECT ... FOR SHARE/UPDATE without
specifying explicit columns, like COUNT(*), the existing LOCK command
seems to me odd.

I think this patch fixes the behavior as we expected.

BTW, how about backporting this patch?
It seems to me a bug fix, although it contains user visible changes.

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>