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:26:07 |
Message-ID: | CAM3SWZRDpcB5oCYjzwsCw1wMtp4XKzyU3MDgkkbOB_MBQ3NpqA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 1, 2015 at 4:17 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2015-10-01 16:13:12 -0700, Peter Geoghegan wrote:
>> However, we're checking the excluded tuple (the might-be-inserted,
>> might-be-excluded tuple that reflects before row insert trigger
>> effects) with WCO_RLS_INSERT_CHECK, not WCO_RLS_UPDATE_CHECK. The
>> WCO_RLS_UPDATE_CHECK applies to the tuple to be appended to the
>> relation (the tuple that an UPDATE makes supersede some existing
>> tuple, a new row version).
>
> 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).
FWIW, I think that this technically wasn't a bug, because it was based
on a deliberate design decision that I thought (not without
justification) was consistent with what we wanted for RLS across the
board. But, again, happy to go along with what you say in light of
this new information.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-10-01 23:49:37 | Re: ON CONFLICT issues around whole row vars, |
Previous Message | Peter Geoghegan | 2015-10-01 23:19:57 | Re: ON CONFLICT issues around whole row vars, |