Re: unclear about row-level security USING vs. CHECK - Mailing list pgsql-hackers

From Robert Haas
Subject Re: unclear about row-level security USING vs. CHECK
Date
Msg-id CA+TgmoZh7ozBZkiBFmMtj8iGQDSp+WVbBQyhY9BZvL8y25dg2w@mail.gmail.com
Whole thread Raw
In response to Re: unclear about row-level security USING vs. CHECK  (Stephen Frost <sfrost@snowman.net>)
Responses Re: unclear about row-level security USING vs. CHECK  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Wed, Sep 23, 2015 at 2:39 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> On Wed, Sep 23, 2015 at 12:01 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> > * Robert Haas (robertmhaas@gmail.com) wrote:
>> >> My expectation would have been:
>> >>
>> >> If you specify USING, you can see only those rows, but you can give
>> >> rows away freely.  If you don't want to allow giving rows away under
>> >> any circumstances, then specify the same expression for USING and WITH
>> >> CHECK.
>> >
>> > Having an implicit 'true' for WITH CHECK would be very much against what
>> > I would ever expect.  If anything, I'd think we would have an implicit
>> > 'false' there or simply not allow it to ever be unspecified.
>>
>> Huh?  If you had an implicit false, wouldn't that prevent updating or
>> deleting any rows at all?
>
> Right, just the same as how, if RLS is enabled and no explicit policies
> are provided, non-owners can't see the rows or insert/update/delete
> anything in the table.  The same is true for the GRANT system, where
> there are no permissions granted by default.  I view the lack of an
> explicit definition of a WITH CHECK clause to be the same, excepting the
> simple case where it's the same as USING.

Hmm, interesting.  I guess that's a defensible position, but I still
think that having them default to be the same thing implicitly is
kinda weird.  I'll defer to whatever the consensus, is, though.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: No Issue Tracker - Say it Ain't So!
Next
From: Andres Freund
Date:
Subject: Re: Rework the way multixact truncations work