On Thu, Oct 1, 2015 at 4:17 PM, Andres Freund <and...@anarazel.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
