On Wed, Sep 23, 2015 at 11:24 AM, Stephen Frost <sfrost@snowman.net> wrote:
> I'm working on a documentation patch with Adam to improve the docs
> around this (and other parts as well). I agree it doesn't come off as
> naturally intuitive to everyone (it did to me, but I'm clearly biased
> as, I think anyway, it was my idea) and so I'm not sure that's enough.
>
> Is there strong feeling that USING and WITH CHECK should both always be
> required when specifying ALL and UPDATE policies? It's not a difficult
> change to make if people want it.
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.
> I will mention that on another thread there was discussion about having
> WITH CHECK for all policy types as a way to let users control if an
> error should be thrown rather than skipping over a row due to lack of
> visibility. In all cases, USING controls visibility and WITH CHECK will
> throw an error on a violation and that would remain the case with this
> approach. Now that I think about it, it might be a bit cleaner if
> USING and WITH CHECK are always kept independent for that case, but I'm
> not sure it's really all that much of a difference. The USING will
> always be applied first and then the WITH CHECK applied to any rows
> which remain, which comes across, to me at least (which isn't fair, of
> course, but it's what I can comment on) as quite clear to understand.
I don't really get that. If you could make skipping a row trigger an
error, then that would create a bunch of covert channel attacks.
Granted we will have some of those anyway, but I see no reason to
manufacture more. You can set row_security=off if you want an attempt
to query a table with RLS enabled to fail outright, but you're not
entitled to know whether a particular query skipped an invisible row.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
