Stephen Frost <[EMAIL PROTECTED]> writes: > * Tom Lane ([EMAIL PROTECTED]) 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