From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ON CONFLICT issues around whole row vars, |
Date: | 2015-10-01 23:53:16 |
Message-ID: | CAM3SWZSPRQ4D7boRPBksrcqPLRSUGFPKWKkqp9nO=iV80AKUnQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 1, 2015 at 4:26 PM, Peter Geoghegan <pg(at)heroku(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-10-01 23:55:23 | Re: ON CONFLICT issues around whole row vars, |
Previous Message | Andres Freund | 2015-10-01 23:49:37 | Re: ON CONFLICT issues around whole row vars, |