Zhaomo,
* Zhaomo Yang (zmp...@gmail.com) wrote:
> I just tried a little bit your patch for applying SELECT policies to
> DELETE/UPDATE. It is consistent with the GRANT system so it looks
> really good. I'll test it more thoroughly later.
Great! Glad to hear it.
> Also, I guess we don't need to
Stephen,
I just tried a little bit your patch for applying SELECT policies to
DELETE/UPDATE. It is consistent with the GRANT system so it looks
really good. I'll test it more thoroughly later.
Also, I guess we don't need to worry about the syntax of "restrictive
policies" you mentioned in the upt
* Zhaomo Yang (zmp...@gmail.com) wrote:
> > Just a side-note, but your mail client doesn't seem to get the quoting
> > quite right sometimes, which can be confusing. Not sure if there's
> > anything you can do about it but wanted to let you know in case there
> > is.
>
> Sorry about this. From no
Stephen,
> Just a side-note, but your mail client doesn't seem to get the quoting
> quite right sometimes, which can be confusing. Not sure if there's
> anything you can do about it but wanted to let you know in case there
> is.
Sorry about this. From now on I'll use the plain text mode for msgs
Zhaomo,
Just a side-note, but your mail client doesn't seem to get the quoting
quite right sometimes, which can be confusing. Not sure if there's
anything you can do about it but wanted to let you know in case there
is.
* Zhaomo Yang (zmp...@gmail.com) wrote:
> > It'd be great if others who are
Stephen,
It'd be great if others who are interested can help define the grammar
> changes necessary
> and perhaps even help with the code aspect of it.
I'd like to help on both. Can you elaborate a little bit more, especially
on the code aspect?
I don't buy that argument.
It is agreed that blin
Zhaomo,
* Zhaomo Yang (zmp...@gmail.com) wrote:
> > I agree that if we force a single visibility policy for all commands
> > then we wouldn't need the USING clauses for UPDATE and DELETE, but we
> > would certainly need *some* policy for DELETE to prevent users from
> > being able to delete record
Stephen,
> I agree that if we force a single visibility policy for all commands
> then we wouldn't need the USING clauses for UPDATE and DELETE, but we
> would certainly need *some* policy for DELETE to prevent users from
> being able to delete records that they aren't supposed to be allowed to.
>
Zhaomo,
* Zhaomo Yang (zmp...@gmail.com) wrote:
> I admit that I gave some bad examples in the previous email, and it is fair
> to say
> this (Being able to have something like NEW.value > 10 OR OLD.id = 1) is
> not a advantage of what I proposed
> before I can come up with any real-world examples
>
> I really don't like the approach you're suggesting above where an 'OR'
> inside of
> such a clause could mean that users can arbitrarly change any existing row
> without any further check on that row and I have a hard time seeing the
> use-case which justifies the additional complexity and user
Zhaomo,
* Zhaomo Yang (zmp...@gmail.com) wrote:
> > If no NEW or OLD is used, what happens? Or would you have
> > to always specify OLD/NEW for UPDATE, and then what about for the other
> > policies, and the FOR ALL policies?
>
> I should be clearer with references to OLD/NEW. SELECT Predicates
Stephen,
If no NEW or OLD is used, what happens? Or would you have
> to always specify OLD/NEW for UPDATE, and then what about for the other
> policies, and the FOR ALL policies?
I should be clearer with references to OLD/NEW. SELECT Predicates cannot
reference any of them.
INSERT predicates ca
Zhaomo,
* Zhaomo Yang (zmp...@gmail.com) wrote:
> This thread has a pretty thorough discussion of pros and cons of applying
> SELECT policy to other commands. Besides what have been mentioned, I think
> there is another potential pro: we can enable references to pseudorelations
> OLD and NEW in pr
In case you missed the link to the previous discussion at the bottom,
http://www.postgresql.org/message-id/CAHGQGwEqWD=ynqe+zojbpoxywt3xlk52-v_q9s+xofckjd5...@mail.gmail.com
Hi,
This thread has a pretty thorough discussion of pros and cons of applying
SELECT policy to other commands. Besides what have been mentioned, I think
there is another potential pro: we can enable references to pseudorelations
OLD and NEW in predicates. Now, for UPDATE, the references to the tar
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 8 June 2015 at 16:53, Stephen Frost wrote:
> > I definitely don't like the idea of returning a portion of the data in a
> > RETURNING clause. Returning an error if the RETURNING clause ends up
> > not passing the SELECT policy is an int
On 8 June 2015 at 16:53, Stephen Frost wrote:
> I definitely don't like the idea of returning a portion of the data in a
> RETURNING clause. Returning an error if the RETURNING clause ends up
> not passing the SELECT policy is an interesting idea, but I do have
> doubts about how often that will
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 6 June 2015 at 22:16, Peter Geoghegan wrote:
> > On Fri, Oct 17, 2014 at 5:34 AM, Andres Freund
> > wrote:
> >> On 2014-10-17 14:57:03 +0800, Craig Ringer wrote:
> >>> On 10/17/2014 02:49 AM, Robert Haas wrote:
> >>> > I think you could proba
On 6 June 2015 at 22:16, Peter Geoghegan wrote:
> On Fri, Oct 17, 2014 at 5:34 AM, Andres Freund wrote:
>> On 2014-10-17 14:57:03 +0800, Craig Ringer wrote:
>>> On 10/17/2014 02:49 AM, Robert Haas wrote:
>>> > I think you could probably make the DELETE policy control what can get
>>> > deleted, b
On Fri, Oct 17, 2014 at 5:34 AM, Andres Freund wrote:
> On 2014-10-17 14:57:03 +0800, Craig Ringer wrote:
>> On 10/17/2014 02:49 AM, Robert Haas wrote:
>> > I think you could probably make the DELETE policy control what can get
>> > deleted, but then have the SELECT policy further filter what gets
On 2014-10-17 14:57:03 +0800, Craig Ringer wrote:
> On 10/17/2014 02:49 AM, Robert Haas wrote:
> > I think you could probably make the DELETE policy control what can get
> > deleted, but then have the SELECT policy further filter what gets
> > returned.
>
> That seems like the worst of both worlds
On Fri, Oct 17, 2014 at 7:46 AM, Stephen Frost wrote:
> Thoughts on 'WITH RETURNING' / 'WITHOUT RETURNING' and what the default
> should be?
That sounds like a horrendous pile of nasty complication for no good purpose.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Post
* David G Johnston (david.g.johns...@gmail.com) wrote:
> How about returning a placeholder row but with all the values replaced with
> NULL?
I don't think that would be a good approach.. A user actually looking
at those rows would be highly confused.
> In the absence of returning does the delete
* Thom Brown (t...@linux.com) wrote:
> On 17 October 2014 07:57, Craig Ringer wrote:
> > On 10/17/2014 02:49 AM, Robert Haas wrote:
> > > I think you could probably make the DELETE policy control what can get
> > > deleted, but then have the SELECT policy further filter what gets
> > > returned.
>
* Fujii Masao (masao.fu...@gmail.com) wrote:
> Another minor problem that I found is that pg_dump always fails when
> there is a row-level policy for update. I think that the attached patch
> should be applied.
Urgh. That was tested before but we switched the characters used and
evidently missed
On Fri, Oct 17, 2014 at 3:49 AM, Robert Haas wrote:
>>> That's an argument in favour of only applying a read-filtering policy
>>> where a RETURNING clause is present, but that introduces the "surprise!
>>> the effects of your DELETE changed based on an unrelated clause!" issue.
>>
>> No- if we wer
On 17 October 2014 07:57, Craig Ringer wrote:
> On 10/17/2014 02:49 AM, Robert Haas wrote:
> > I think you could probably make the DELETE policy control what can get
> > deleted, but then have the SELECT policy further filter what gets
> > returned.
>
> That seems like the worst of both worlds to
Robert Haas wrote
>>> That's an argument in favour of only applying a read-filtering policy
>>> where a RETURNING clause is present, but that introduces the "surprise!
>>> the effects of your DELETE changed based on an unrelated clause!" issue.
>>
>> No- if we were going to do this, I wouldn't want
On 10/17/2014 02:49 AM, Robert Haas wrote:
> I think you could probably make the DELETE policy control what can get
> deleted, but then have the SELECT policy further filter what gets
> returned.
That seems like the worst of both worlds to me.
Suddenly DELETE ... RETURNING might delete more rows
>> That's an argument in favour of only applying a read-filtering policy
>> where a RETURNING clause is present, but that introduces the "surprise!
>> the effects of your DELETE changed based on an unrelated clause!" issue.
>
> No- if we were going to do this, I wouldn't want to change the existing
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> On 10/16/2014 01:44 PM, Craig Ringer wrote:
> > So the read-filtering policy should apply to all statements. Not just
> > SELECT.
>
> Oh, IIRC one wrinkle in the prior discussion about this was that doing
> this will prevent the implementation of pol
Fujii,
* Fujii Masao (masao.fu...@gmail.com) wrote:
> While I was checking the behavior of RLS, I found that the policy for SELECT
> doesn't seem to be applied to RETURNING. Is this intentional? Please see
> the following example.
Yes, it was intentional. That said, I'm not against changing it.
On 10/16/2014 01:44 PM, Craig Ringer wrote:
> So the read-filtering policy should apply to all statements. Not just
> SELECT.
Oh, IIRC one wrinkle in the prior discussion about this was that doing
this will prevent the implementation of policies that permit users to
update/delete rows they cannot
On 10/16/2014 12:25 PM, Fujii Masao wrote:
> Hi,
>
> While I was checking the behavior of RLS, I found that the policy for SELECT
> doesn't seem to be applied to RETURNING. Is this intentional?
This is why I was opposed to having a "SELECT" policy at all. It should
be "VISIBLE", "INSERT", "UPDAT
Hi,
While I was checking the behavior of RLS, I found that the policy for SELECT
doesn't seem to be applied to RETURNING. Is this intentional? Please see
the following example.
CREATE ROLE foo LOGIN NOSUPERUSER;
CREATE TABLE hoge AS SELECT col FROM generate_series(1,10) col;
ALTER TABLE hoge ENAB
35 matches
Mail list logo
