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 it'l
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 "rules"
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
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 documentation could also be
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 documentation could also be
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 documentation could also be impr
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 set of minor release
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
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
> > (staff/account admins) can see rec
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 why a grant for ALL sho
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 grant per relevant op
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 time
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 (robertmh...@gmail.com) wrote:
>> > >> On Thu, Apr
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 valu
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
> wrote:
> > >> > I'm a little conf
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 NEW record
> >> > for an
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 policies. The ALL policy doesn'
* 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 restriction.
>
> My guess
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.
--
Robert Haas
Enterpris
19 matches
Mail list logo