Re: [PATCHES] column level privileges - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] column level privileges
Date
Msg-id 28644.1210126742@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] column level privileges  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [PATCHES] column level privileges  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> What I think would be a more desirable solution is that the table ACL
>> still sets the table-level INSERT or UPDATE privilege bit as long as
>> you have any such privilege. ...

> I agree with this approach and feel it's alot cleaner as well as faster.
> We definitely don't want to make permission checking take any more time
> than it absolutely has to.

It occurs to me that there's something else to be thought about here.
Given a table against which some per-column GRANTs/REVOKEs have been
issued, what is the proper privilege state for a newly added column?
I'm feeling too lazy right now to try to deconstruct what the spec
says about it, if it says anything.  However, I'm pretty sure that the
patch-as-given doesn't behave very reasonably (or backwards compatibly)
on the point: it's going to end up with no privileges on the new column,
whereas our historical behavior is that the new column is accessible to
anyone with table-level privileges.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] [badalex@gmail.com: Re: [BUGS] Problem identifying constraints which should not be inherited]
Next
From: "Alex Hunsaker"
Date:
Subject: Re: [PATCHES] [badalex@gmail.com: Re: [BUGS] Problem identifying constraints which should not be inherited]