Re: ON CONFLICT issues around whole row vars, - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: ON CONFLICT issues around whole row vars,
Date
Msg-id CAM3SWZSPRQ4D7boRPBksrcqPLRSUGFPKWKkqp9nO=iV80AKUnQ@mail.gmail.com
Whole thread Raw
In response to Re: ON CONFLICT issues around whole row vars,  (Peter Geoghegan <pg@heroku.com>)
Responses Re: ON CONFLICT issues around whole row vars,  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Thu, Oct 1, 2015 at 4:26 PM, Peter Geoghegan <pg@heroku.com> wrote:
>> You can already see the effects of an INSERT modified by before triggers
>> via RETURNING. No?
>
> I'm not saying that I agree with the decision to not do anything
> special with RLS + RETURNING in general. I'm also not going to say
> that I disagree with it. As I said, I missed that decision until just
> now. I agree that it's obviously true that what you propose is
> consistent with what is now considered ideal behavior for RLS (that's
> what I get from the wiki page comments on RLS + RETURNING).

I see now that commit 4f3b2a8883 changed things for UPDATE and DELETE
statements, but not INSERT statements. I guess my unease is because
that isn't entirely consistent with INSERT + RETURNING and the GRANT
system. Logically, the only possible justification for our long
standing INSERT and RETURNING behavior with GRANT (the fact that it
requires SELECT privilege for rows returned, just like UPDATE and
DELETE) is that before row insert triggers could do something secret
(e.g. they could be security definer). It doesn't seem to be too much
of a stretch to suppose the same should apply with RLS.


-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: ON CONFLICT issues around whole row vars,
Next
From: Peter Geoghegan
Date:
Subject: Re: ON CONFLICT issues around whole row vars,