Re: [HACKERS] Row Level Security UPDATE Confusion

Rod, * Rod Taylor (rod.tay...@gmail.com) wrote: > UPDATE seems to work as described (unable to create records you cannot > select); both the single rule version and multi-rule version seem to work > the same. Thanks for reporting this and helping to test the fix. I've now pushed the fix and

Re: [HACKERS] Row Level Security UPDATE Confusion

Rod, * Rod Taylor (rod.tay...@gmail.com) wrote: > UPDATE seems to work as described (unable to create records you cannot > select); both the single rule version and multi-rule version seem to work > the same. I'm glad they work the same now, as they were always intended to. Regarding the

Re: [HACKERS] Row Level Security UPDATE Confusion

Hmm. UPDATE seems to work as described (unable to create records you cannot select); both the single rule version and multi-rule version seem to work the same. This combination works too though it seems funny that UPDATE can create an entry it cannot reverse. I can set the value to 100 (going to

Re: [HACKERS] Row Level Security UPDATE Confusion

Rod, Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Apr 14, 2017 at 9:16 AM, Stephen Frost wrote: > > I agreed already up-thread that there's an issue there and will be > > looking to fix it. That comment was simply replying to Rod's point that > > the

Re: [HACKERS] Row Level Security UPDATE Confusion

Robert, all, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Apr 14, 2017 at 9:16 AM, Stephen Frost wrote: > > I agreed already up-thread that there's an issue there and will be > > looking to fix it. That comment was simply replying to Rod's point that > > the

Re: [HACKERS] Row Level Security UPDATE Confusion

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Apr 14, 2017 at 9:16 AM, Stephen Frost wrote: > > I agreed already up-thread that there's an issue there and will be > > looking to fix it. That comment was simply replying to Rod's point that > > the

Re: [HACKERS] Row Level Security UPDATE Confusion

On Fri, Apr 14, 2017 at 9:16 AM, Stephen Frost wrote: > I agreed already up-thread that there's an issue there and will be > looking to fix it. That comment was simply replying to Rod's point that > the documentation could also be improved. OK, thanks. The wrap for the next

Re: [HACKERS] Row Level Security UPDATE Confusion

Rod, * Rod Taylor (rod.tay...@gmail.com) wrote: > Yep. It's equivalent to a DELETE or DEACTIVATE. RLS may not be the right > facility but it was very close to working exactly the way I wanted in FOR > ALL mode. Turning an UPDATE into, effectively, a DELETE, does seem like it's beyond the mandate

Re: [HACKERS] Row Level Security UPDATE Confusion

On Fri, Apr 14, 2017 at 9:09 AM, Stephen Frost wrote: > Rod, > > * Rod Taylor (rod.tay...@gmail.com) wrote: > > My actual use-case involves a range. Most users can see and manipulate > the > > record when CURRENT_TIMESTAMP is within active_period. Some users > >

Re: [HACKERS] Row Level Security UPDATE Confusion

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Apr 14, 2017 at 9:09 AM, Stephen Frost wrote: > > I agree that the documentation could be improved here. > > This does not seem like it's only a documentation problem. There > seems to be no principled reason

Re: [HACKERS] Row Level Security UPDATE Confusion

On Fri, Apr 14, 2017 at 9:09 AM, Stephen Frost wrote: > I agree that the documentation could be improved here. This does not seem like it's only a documentation problem. There seems to be no principled reason why a grant for ALL shouldn't have exactly the same effect as one

Re: [HACKERS] Row Level Security UPDATE Confusion

Rod, * Rod Taylor (rod.tay...@gmail.com) wrote: > My actual use-case involves a range. Most users can see and manipulate the > record when CURRENT_TIMESTAMP is within active_period. Some users > (staff/account admins) can see recently dead records too. And a 3rd group > (senior staff) have no

Re: [HACKERS] Row Level Security UPDATE Confusion

On Fri, Apr 14, 2017 at 7:41 AM, Rod Taylor wrote: > > > > On Thu, Apr 13, 2017 at 5:31 PM, Stephen Frost wrote: > >> Rod, all, >> >> * Joe Conway (m...@joeconway.com) wrote: >> > On 04/13/2017 01:31 PM, Stephen Frost wrote: >> > > * Robert Haas

Re: [HACKERS] Row Level Security UPDATE Confusion

Rod, * Rod Taylor (rod.tay...@gmail.com) wrote: > Then there is a bug in the simpler statement which happily lets you give > away records. > > CREATE POLICY simple_all ON t TO simple USING (value > 0) WITH CHECK (true); > > SET session authorization simple; > SELECT * FROM t; > UPDATE t SET

Re: [HACKERS] Row Level Security UPDATE Confusion

On Thu, Apr 13, 2017 at 5:31 PM, Stephen Frost wrote: > Rod, all, > > * Joe Conway (m...@joeconway.com) wrote: > > On 04/13/2017 01:31 PM, Stephen Frost wrote: > > > * Robert Haas (robertmh...@gmail.com) wrote: > > >> On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor

Re: [HACKERS] Row Level Security UPDATE Confusion

Rod, all, * Joe Conway (m...@joeconway.com) wrote: > On 04/13/2017 01:31 PM, Stephen Frost wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > >> On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote: > >> > I'm a little confused on why a SELECT policy fires against the

Re: [HACKERS] Row Level Security UPDATE Confusion

On 04/13/2017 01:31 PM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote: >> > I'm a little confused on why a SELECT policy fires against the NEW record >> > for an UPDATE when using multiple FOR

Re: [HACKERS] Row Level Security UPDATE Confusion

* Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote: > > I'm a little confused on why a SELECT policy fires against the NEW record > > for an UPDATE when using multiple FOR policies. The ALL policy doesn't seem > > to have that

Re: [HACKERS] Row Level Security UPDATE Confusion

On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote: > I'm a little confused on why a SELECT policy fires against the NEW record > for an UPDATE when using multiple FOR policies. The ALL policy doesn't seem > to have that restriction. My guess is that you have found a bug. --

[HACKERS] Row Level Security UPDATE Confusion

I'm a little confused on why a SELECT policy fires against the NEW record for an UPDATE when using multiple FOR policies. The ALL policy doesn't seem to have that restriction. DROP TABLE IF EXISTS t; CREATE USER simple; CREATE USER split; CREATE TABLE t(value int); grant select, update on table