Skip site navigation (1) Skip section navigation (2)

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

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Josh Kupershmidt <schmiddy(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] column-level update privs + lock table
Date: 2010-11-26 01:29:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
(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.

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

In response to


pgsql-hackers by date

Next:From: Fujii MasaoDate: 2010-11-26 02:19:34
Subject: Re: Assertion failure on hot standby
Previous:From: Chang ChaoDate: 2010-11-26 00:44:01
Subject: Re: [COMMITTERS] How strings are sorted by LC_COLLATE specifically?

pgsql-general by date

Next:From: James B. ByrneDate: 2010-11-26 02:21:13
Subject: PGError: ERROR: missing FROM-clause entry for table
Previous:From: Kevin & Jessica HermansenDate: 2010-11-25 23:13:13
Subject: Dear Friends: a 123h

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group