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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers