Re: about truncate
От | Peter Eisentraut |
---|---|
Тема | Re: about truncate |
Дата | |
Msg-id | 496755BF.6000208@gmx.net обсуждение исходный текст |
Ответ на | Re: about truncate (David Fetter <david@fetter.org>) |
Ответы |
Re: about truncate
|
Список | pgsql-hackers |
David Fetter wrote: > On Thu, Jan 08, 2009 at 02:39:52PM +0200, Peter Eisentraut wrote: >> David Fetter wrote: >>> +1 for adding recursion to GRANT/REVOKE :) >> This area is under SQL standard control, so we can't really invent our >> own behavior. >> >> Consider the following: >> >> CREATE TABLE persons (name, email); >> CREATE TABLE employees (grade, salary) INHERITS (persons); >> >> GRANT SELECT ON persons TO allstaff; -- ??? >> GRANT SELECT ON employees TO managers; >> >> What you want in practice is that allstaff can read only those columns >> of employees that come from the persons table. Both recursive and >> nonrecursive GRANT do the wrong thing here. > > What *would* do the right thing here, or would anything? I think we don't need GRANT to be recursive, but instead the permission checks at runtime should allow SELECT * FROM persons; to succeed even if there are no permissions on "employees". But only on the columns of "persons" and only if actually queried through "persons". Needs a more detailed analysis, but that is how I imagine it ought to work.
В списке pgsql-hackers по дате отправления: