2010/11/25 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> (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
>>>> 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.
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
> BTW, how about backporting this patch?
> It seems to me a bug fix, although it contains user visible changes.
I don't think it's a bug fix; and even if could be so construed, I
don't think it's important enough to back-patch.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2010-11-27 00:16:20|
|Subject: Re: Re: [BUGS] BUG #5650: Postgres service showing as
stopped when in fact it is running|
|Previous:||From: Robert Haas||Date: 2010-11-27 00:02:27|
|Subject: Re: Assertion failure on hot standby|
pgsql-general by date
|Next:||From: Zhipan Wang||Date: 2010-11-27 08:52:56|
|Subject: Question about OID and TCID|
|Previous:||From: Craig Ringer||Date: 2010-11-26 23:49:25|
|Subject: Re: Terms advice.|