Re: [PATCHES] column level privileges

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] column level privileges
Date: 2008-05-07 02:19:02
Message-ID: 28644.1210126742@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2008-05-07 02:34:17 Re: [HACKERS] [GENERAL] psql \pset pager
Previous Message Tom Lane 2008-05-07 01:57:30 Re: [PATCHES] [badalex@gmail.com: Re: [BUGS] Problem identifying constraints which should not be inherited]