* Peter Geoghegan (pg@heroku.com) wrote:
> On Tue, Sep 29, 2015 at 8:24 AM, Andres Freund <andres@anarazel.de> wrote:
> > So, took a bit longer than "tomorrow. I fought for a long while with a
> > mysterious issue, which turned out to be separate bug: The excluded
> > relation was affected by row level security policies, which doesn't make
> > sense.
>
> Why? You certainly thought that it made sense for conventional column
> permissions due to potential problems with before row insert triggers.
> Why would RLS be different? Some of my concerns with RLS were that it
> is different to the existing permissions model in a way that seems a
> bit arbitrary. I don't think that they were changed to do anything
> special with SELECT ... FOR UPDATE, which has always required some
> amount of conventional UPDATE privilege.
I'm just about to push a patch to address exactly the SELECT .. FOR
UPDATE case, actually, and to try and make sure that RLS is more in line
with the existing permissions model.. I admit that I've not been
entirely following this thread though, so I'm not quite sure how that's
relevant to this discussion.
From Andres' reply, it looks like this is about the EXCLUDED pseudo
relation which comes from the INSERT'd values themselves, in which case,
I tend to agree with his assessment that it doesn't make sense for those
to be subject to RLS policies, given that it's all user-provided data,
as long as the USING check is done on the row found to be conflicting
and the CHECK constraints are dealt with correctly for any row added,
which I believe is what we had agreed was the correct way to handle this
case in prior discussions.
Thanks!
Stephen
