Re: Possible typo in create_policy.sgml

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Possible typo in create_policy.sgml
Дата
Msg-id CA+TgmobUv4tZEzkkzNrwVbOerNcVUMq91xbVjUkx67zm43JwRg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Possible typo in create_policy.sgml  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Possible typo in create_policy.sgml  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On Fri, Jan 9, 2015 at 3:46 PM, Stephen Frost <sfrost@snowman.net> wrote:
>    A policy permits SELECT, INSERT, UPDATE or DELETE commands to access rows
>    in a table that has row level security enabled.  Access to existing table
>    rows is granted if they match a policy expression specified via USING,
>    while new rows that would be created via INSERT or UPDATE are checked
>    against policy expressions specified via WITH CHECK.  For policy
>    expressions specified via USING which grant access to existing rows, the
>    system will generally test the policy expressions prior to any
>    qualifications that appear in the query itself, in order to the prevent the
>    inadvertent exposure of the protected data to user-defined functions which
>    might not be trustworthy.  However, functions and operators marked by the
>    system (or the system administrator) as LEAKPROOF may be evaluated before
>    policy expressions, as they are assumed to be trustworthy.

I think that sticking "while new rows that would be created via INSERT
or UPDATE are checked against policy expressions specified via WITH
CHECK" into the middle of this is horribly confusing, as it's a
completely separate mechanism from the rest of what's being discussed
here.  I think there needs to be some initial language that clarifies
that USING expressions apply to old rows and WITH CHECK expressions to
new rows, and then you can go into more detail.  But mentioning WITH
CHECK parenthetically in the middle of the rest of this I think will
not lead to clarity.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: libpq bad async behaviour
Следующее
От: Andres Freund
Дата:
Сообщение: Re: libpq bad async behaviour