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
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
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
* 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
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
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
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
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
>
> 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
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 cannot
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
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
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
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
On 8 June 2015 at 16:53, Stephen Frost sfr...@snowman.net 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
On 6 June 2015 at 22:16, Peter Geoghegan p...@heroku.com wrote:
On Fri, Oct 17, 2014 at 5:34 AM, Andres Freund and...@2ndquadrant.com 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
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 6 June 2015 at 22:16, Peter Geoghegan p...@heroku.com wrote:
On Fri, Oct 17, 2014 at 5:34 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-10-17 14:57:03 +0800, Craig Ringer wrote:
On 10/17/2014 02:49 AM, Robert Haas wrote:
I
On Fri, Oct 17, 2014 at 5:34 AM, Andres Freund and...@2ndquadrant.com 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
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
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 to change the
On 17 October 2014 07:57, Craig Ringer cr...@2ndquadrant.com 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
On Fri, Oct 17, 2014 at 3:49 AM, Robert Haas robertmh...@gmail.com 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
* 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
* Thom Brown (t...@linux.com) wrote:
On 17 October 2014 07:57, Craig Ringer cr...@2ndquadrant.com 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
* 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
On Fri, Oct 17, 2014 at 7:46 AM, Stephen Frost sfr...@snowman.net 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
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 to me.
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.
* 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 policies
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
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, UPDATE, DELETE.
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
33 matches
Mail list logo
