Re: RLS Design
От | Thom Brown |
---|---|
Тема | Re: RLS Design |
Дата | |
Msg-id | CAA-aLv6HuzSuYSceM0k9D3iOzod7GQYnCyXWMv6XUMVkS3idOg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RLS Design (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: RLS Design
(Stephen Frost <sfrost@snowman.net>)
|
Список | pgsql-hackers |
On 19 September 2014 17:54, Stephen Frost <sfrost@snowman.net> wrote: > > Thom, > > * Thom Brown (thom@linux.com) wrote: > > On 19 September 2014 17:32, Stephen Frost <sfrost@snowman.net> wrote: > > > * Thom Brown (thom@linux.com) wrote: > > > > On 14 September 2014 16:38, Stephen Frost <sfrost@snowman.net> wrote: > > > > # create policy visible_colours on colours for all to joe using (visible > > > = > > > > true); > > > > CREATE POLICY > > > [...] > > > > > insert into colours (name, visible) values ('transparent',false); > > > > ERROR: new row violates WITH CHECK OPTION for "colours" > > > > DETAIL: Failing row contains (7, transparent, f). > > > > > > > > > select * from pg_policies ; > > > > policyname | tablename | roles | cmd | qual | > > > with_check > > > > > > > -----------------+-----------+-------+-----+------------------+------------ > > > > visible_colours | colours | {joe} | ALL | (visible = true) | > > > > (1 row) > > > > > > > > There was no WITH CHECK OPTION. > > > > > > As I hope is clear if you look at the documentation- if the WITH CHECK > > > clause is omitted, then the USING clause is used for both filtering and > > > checking new records, otherwise you'd be able to add records which > > > aren't visible to you. > > > > I can see that now, although I do find the error message somewhat > > confusing. Firstly, it looks like "OPTION" is part of the parameter name, > > which it isn't. > > Hmm, the notion of 'with check option' is from the SQL standard, which > is why I felt the error message was appropriate as-is.. > > > Also, I seem to get an error message with the following: > > > > # create policy nice_colours ON colours for all to joe using (visible = > > true) with check (name in ('blue','green','yellow')); > > CREATE POLICY > > > > \c - joe > > > > > insert into colours (name, visible) values ('blue',false); > > ERROR: function with OID 0 does not exist > > Now *that* one is interesting and I'll definitely go take a look at it. > We added quite a few regression tests to try and make sure these things > work. > > > And if this did work, but I only violated the USING clause, would this > > still say the WITH CHECK clause was the cause? > > WITH CHECK applies for INSERT and UPDATE for the new records going into > the table. You can't actually violate the USING clause for an INSERT > as USING is for filtering records, not checking that records being added > to the table are valid. > > To try and clarify- by explicitly setting both USING and WITH CHECK, you > *are* able to INSERT records which are not visible to you. We felt that > was an important capability to support. I find it a bit of a limitation that I can't specify both INSERT and UPDATE for a policy. I'd want to be able to specify something like this: CREATE POLICY no_greys_allowed ON colours FOR INSERT, UPDATE WITH CHECK (name NOT IN ('grey','gray')); I would expect this to be rather common to prevent certain values making their way into a table. Instead I'd have to create 2 policies as it stands. In order to debug issues with accessing table data, perhaps it would be useful to output the name of the policy that was violated. If a table had 20 policies on, it could become time-consuming to debug. I keep getting tripped up by overlapping policies. On the one hand, I created a policy to ensure rows being added or selected have a "visible" column set to true. On the other hand, I have a policy that ensures that the name of a colour doesn't appear in a list. Policy 1 is violated until policy 2 is added: (using the table I created in a previous post on this thread...) # create policy must_be_visible ON colours for all to joe using (visible = true) with check (visible = true); CREATE POLICY \c - joe > insert into colours (name, visible) values ('pink',false); ERROR: new row violates WITH CHECK OPTION for "colours" DETAIL: Failing row contains (28, pink, f). \c - thom # create policy no_greys_allowed on colours for insert with check (name not in ('grey','gray')); CREATE POLICY \c - joe # insert into colours (name, visible) values ('pink',false); INSERT 0 1 I expected this to still trigger an error due to the first policy. Am I to infer from this that the policy model is permissive rather than restrictive? I've also attached a few corrections for the docs. Thom
Вложения
В списке pgsql-hackers по дате отправления:
Следующее
От: Simon RiggsДата:
Сообщение: Re: a fast bloat measurement tool (was Re: Measuring relation free space)