Re: unclear about row-level security USING vs. CHECK
От | Peter Eisentraut |
---|---|
Тема | Re: unclear about row-level security USING vs. CHECK |
Дата | |
Msg-id | 56074A78.9070403@gmx.net обсуждение исходный текст |
Ответ на | Re: unclear about row-level security USING vs. CHECK (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: unclear about row-level security USING vs. CHECK
Re: unclear about row-level security USING vs. CHECK |
Список | pgsql-hackers |
On 9/23/15 3:41 PM, Stephen Frost wrote: > The CREATE POLICY documentation discusses how lack of a WITH CHECK > policy means the USING expression is used: > > """ > Policies can be applied for specific commands or for specific roles. The > default for newly created policies is that they apply for all commands > and roles, unless otherwise specified. If multiple policies apply to a > given query, they will be combined using OR (although ON CONFLICT DO > UPDATE and INSERT policies are not combined in this way, but rather > enforced as noted at each stage of ON CONFLICT execution). Further, for > commands which can have both USING and WITH CHECK policies (ALL and > UPDATE), if no WITH CHECK policy is defined then the USING policy will > be used for both what rows are visible (normal USING case) and which > rows will be allowed to be added (WITH CHECK case). > """ I see. But it is a bit odd to hide this very fundamental behavior somewhere in a paragraph that starts out with something about roles. There is also a mistake, I believe: DELETE policies also take both a CHECK and a USING clause. I still find something about this weird, but I'm not sure what. It's not clear to me at what level this USING->CHECK mapping is applied. I can write FOR ALL USING and it will be mapped to CHECK for all actions, including INSERT, but when I write FOR INSERT USING it complains. Why doesn't it do the mapping that case, too? >> (Btw., what's the meaning of a policy for DELETE?) > > The DELETE policy controls what records a user is able to delete. That needs to be documented somewhere.
В списке pgsql-hackers по дате отправления: