Re: WITH CHECK and Column-Level Privileges
От | Dean Rasheed |
---|---|
Тема | Re: WITH CHECK and Column-Level Privileges |
Дата | |
Msg-id | CAEZATCU5SCZyhz7C4KxCct1UR9y02ALs1Ur1+bRns5vbpKHNGw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WITH CHECK and Column-Level Privileges (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: WITH CHECK and Column-Level Privileges
|
Список | pgsql-hackers |
On 29 October 2014 13:04, Stephen Frost <sfrost@snowman.net> wrote: > * Robert Haas (robertmhaas@gmail.com) wrote: >> On Wed, Oct 29, 2014 at 8:16 AM, Stephen Frost <sfrost@snowman.net> wrote: >> > suggestions. If the user does not have table-level SELECT rights, >> > they'll see for the "Failing row contains" case, they'll get: >> > >> > Failing row contains (col1, col2, col3) = (1, 2, 3). >> > >> > Or, if they have no access to any columns: >> > >> > Failing row contains () = () >> >> I haven't looked at the code, but that sounds nice, except that if >> they have no access to any columns, I'd leave the message out >> altogether instead of emitting it with no useful content. > > Alright, I can change things around to make that happen without too much > trouble. > Yes, skim-reading the patch, it looks like a good approach to me, and also +1 for not emitting anything if no values are visible. I fear, however, that for updatable views, in the most common case, the user won't have any permissions on the underlying table, and so the error detail will always be omitted. I wonder if one way we can improve upon that is to include the RTE's modifiedCols set in the set of columns the user can see, since for those columns what we would be reporting are the new user-supplied values, and so there is no information leakage. Regards, Dean
В списке pgsql-hackers по дате отправления: