* Peter Geoghegan (p...@heroku.com) wrote: > On Tue, Sep 29, 2015 at 8:24 AM, Andres Freund <and...@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
signature.asc
Description: Digital signature
