* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> Don't forget the ALTER POLICY page. This and some of the other things
> being discussed on this thread ought to be copied there too.
Thanks, I've fixed this also.
Stephen
signature.asc
Description: Digital signature
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 30 January 2015 at 03:40, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Thu, Jan 29, 2015 at 9:04 PM, Stephen Frost wrote:
> >> > A policy grants the ability to SELECT, INSERT, UPDATE, or DELETE rows
> >> > whic
On 30 January 2015 at 03:40, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Jan 29, 2015 at 9:04 PM, Stephen Frost wrote:
>> > A policy grants the ability to SELECT, INSERT, UPDATE, or DELETE rows
>> > which match the relevant policy expression. Existing table rows
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jan 29, 2015 at 9:04 PM, Stephen Frost wrote:
> > A policy grants the ability to SELECT, INSERT, UPDATE, or DELETE rows
> > which match the relevant policy expression. Existing table rows are
> > checked against the expression specified via US
On Thu, Jan 29, 2015 at 9:04 PM, Stephen Frost wrote:
> A policy grants the ability to SELECT, INSERT, UPDATE, or DELETE rows
> which match the relevant policy expression. Existing table rows are
> checked against the expression specified via USING, while new rows
> that would be created via INSER
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 28, 2015 at 10:45 PM, Stephen Frost wrote:
> > I agree, especially after going back and re-reading this while fixing
> > the issue mentioned earlier by Peter (which was an orthogonal complaint
> > about the shadowing of WITH CHECK by USING
On Wed, Jan 28, 2015 at 10:45 PM, Stephen Frost wrote:
> I agree, especially after going back and re-reading this while fixing
> the issue mentioned earlier by Peter (which was an orthogonal complaint
> about the shadowing of WITH CHECK by USING, if WITH CHECK isn't
> specified). We really need a
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 29 January 2015 at 04:00, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Wed, Jan 7, 2015 at 3:06 PM, Stephen Frost wrote:
> >> > If I'm following correctly, Peter's specifically talking about:
> >> >
> >> >
On 29 January 2015 at 04:00, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Wed, Jan 7, 2015 at 3:06 PM, Stephen Frost wrote:
>> > If I'm following correctly, Peter's specifically talking about:
>> >
>> > [ USING ( expression ) ]
>> > [ WITH CHECK ( > > class="p
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> [There's also a typo further down -- "filter out the records which are
> visible", should be "not visible"]
I agree, that's not really worded quite right. I've reworded this along
the lines of what you suggested (though not exactly- if you
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 7, 2015 at 3:06 PM, Stephen Frost wrote:
> > If I'm following correctly, Peter's specifically talking about:
> >
> > [ USING ( expression ) ]
> > [ WITH CHECK ( > class="parameter">check_expression ) ]
> >
> > Where the USING para
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 9, 2015 at 3:46 PM, Stephen Frost 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
Peter,
* Peter Geoghegan (p...@heroku.com) wrote:
> I also don't see this behavior documented (this is from process_policies()):
[...]
> But is that really the right place for it? Does it not equally well
> apply to FOR UPDATE policies, that can on their own have both barriers
> quals and WITH CHE
On Fri, Jan 9, 2015 at 3:46 PM, Stephen Frost 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
On 9 January 2015 at 20:46, Stephen Frost wrote:
> I'd suggest we further clarify
> with:
>
>The CREATE POLICY command defines a new policy for a
>table. Note that row level security must also be enabled on the table
> using
>ALTER TABLE in order for created policies to be applied.
>
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 8 January 2015 at 18:57, Stephen Frost wrote:
> >> What do you think of the attached rewording?
> >
> > Rewording it this way is a great idea. Hopefully that will help address
> > the confusion which we've seen. The only comment I have
On 8 January 2015 at 18:57, Stephen Frost wrote:
>> What do you think of the attached rewording?
>
> Rewording it this way is a great idea. Hopefully that will help address
> the confusion which we've seen. The only comment I have offhand is:
> should we should add a sentence to this paragraph a
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> [There's also a typo further down -- "filter out the records which are
> visible", should be "not visible"]
>
> What do you think of the attached rewording?
Rewording it this way is a great idea. Hopefully that will help address
the confu
On 8 January 2015 at 08:30, Dean Rasheed wrote:
> I have a wider concern about the wording on this page - both the
> rewritten paragraph and elsewhere talk about policies in terms of
> limiting access to or filtering out rows.
>
> However, since policy expressions are OR'ed together and there is a
On 6 January 2015 at 19:25, Stephen Frost wrote:
> Robert, Amit,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
>> I don't think that's a typo, although it's not particularly
>> well-worded IMHO. I might rewrite the whole paragraph like this:
>>
>> A policy limits the ability to SELECT, INSERT,
On Wed, Jan 7, 2015 at 12:06 PM, Stephen Frost wrote:
> Where the USING parameter is 'expression' but the WITH CHECK parameter
> is 'check_expression'. He makes a good point, I believe, as
> "expression" is overly generic. I don't like the idea of using
> "barrier_expression" though as that ends
* Peter Geoghegan (p...@heroku.com) wrote:
> I also don't see this behavior documented (this is from process_policies()):
>
> /*
> * If we end up with only USING quals, then use those as
> * WITH CHECK quals also.
> */
> if (with_check_quals == NIL)
> with_check_quals = copyObject(quals);
>
>
On Wed, Jan 7, 2015 at 3:06 PM, Stephen Frost wrote:
> If I'm following correctly, Peter's specifically talking about:
>
> [ USING ( expression ) ]
> [ WITH CHECK ( class="parameter">check_expression ) ]
>
> Where the USING parameter is 'expression' but the WITH CHECK parameter
> is 'chec
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jan 6, 2015 at 4:07 PM, Peter Geoghegan wrote:
> > On Tue, Jan 6, 2015 at 1:03 PM, Robert Haas wrote:
> >> I thought my rewrite clarified this distinction pretty well. Maybe
> >> I'm wrong? We're talking about the same paragraph.
> >
> > So
On Tue, Jan 6, 2015 at 4:07 PM, Peter Geoghegan wrote:
> On Tue, Jan 6, 2015 at 1:03 PM, Robert Haas wrote:
>> I thought my rewrite clarified this distinction pretty well. Maybe
>> I'm wrong? We're talking about the same paragraph.
>
> Sorry, I didn't express myself clearly. I think that you di
On 07-01-2015 AM 04:25, Stephen Frost wrote:
> Robert, Amit,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
>> I don't think that's a typo, although it's not particularly
>> well-worded IMHO. I might rewrite the whole paragraph like this:
>>
>> A policy limits the ability to SELECT, INSERT, UPD
I also don't see this behavior documented (this is from process_policies()):
/*
* If we end up with only USING quals, then use those as
* WITH CHECK quals also.
*/
if (with_check_quals == NIL)
with_check_quals = copyObject(quals);
Now, I do see a reference to it under "Per-Command policies -
On Tue, Jan 6, 2015 at 1:03 PM, Robert Haas wrote:
> I thought my rewrite clarified this distinction pretty well. Maybe
> I'm wrong? We're talking about the same paragraph.
Sorry, I didn't express myself clearly. I think that you did get it
right, but I would like to see that distinction also
On Tue, Jan 6, 2015 at 2:48 PM, Peter Geoghegan wrote:
> On Tue, Jan 6, 2015 at 11:25 AM, Stephen Frost wrote:
>> Looks reasonable to me. Amit, does this read better for you? If so, I
>> can handle making the change to the docs.
>
> The docs also prominently say:
>
> "The security-barrier quali
On Tue, Jan 6, 2015 at 11:25 AM, Stephen Frost wrote:
> Looks reasonable to me. Amit, does this read better for you? If so, I
> can handle making the change to the docs.
The docs also prominently say:
"The security-barrier qualifications will always be evaluated prior to
any user-defined funct
Robert, Amit,
* Robert Haas (robertmh...@gmail.com) wrote:
> I don't think that's a typo, although it's not particularly
> well-worded IMHO. I might rewrite the whole paragraph like this:
>
> A policy limits the ability to SELECT, INSERT, UPDATE, or DELETE rows
> in a table to those rows which m
On Tue, Jan 6, 2015 at 12:26 AM, Amit Langote
wrote:
> Following is perhaps a typo:
>
> - qualifications of queries which are run against the table the policy
> is on,
> + qualifications of queries which are run against the table if the
> policy is on,
>
> Attached fixes it if so.
I don't thi
Hi,
Following is perhaps a typo:
- qualifications of queries which are run against the table the policy
is on,
+ qualifications of queries which are run against the table if the
policy is on,
Attached fixes it if so.
Thanks,
Amit
diff --git a/doc/src/sgml/ref/create_policy.sgml b/doc/src/sg
33 matches
Mail list logo
