Re: [PATCHES] column level privileges
От | Tom Lane |
---|---|
Тема | Re: [PATCHES] column level privileges |
Дата | |
Msg-id | 28644.1210126742@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] column level privileges (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: [PATCHES] column level privileges
|
Список | 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 по дате отправления: