On 2015-09-29 15:49:28 -0400, Stephen Frost wrote:
> From Andres' reply, it looks like this is about the EXCLUDED pseudo
> relation which comes from the INSERT'd values themselves
Right.
> 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.
Yes, that what I think as well. At this point we'll already have
executed insert rls stuff on the EXCLUDED tuple: /* * Check any RLS INSERT WITH CHECK policies * *
ExecWithCheckOptions()will skip any WCOs which are not of the kind * we are looking for at this point. */ if
(resultRelInfo->ri_WithCheckOptions!= NIL) ExecWithCheckOptions(WCO_RLS_INSERT_CHECK,
resultRelInfo, slot, estate);
and before executing the actual projection we also checked the existing
tuple: ExecWithCheckOptions(WCO_RLS_CONFLICT_CHECK, resultRelInfo, mtstate->mt_existing,
mtstate->ps.state);
after the update triggers have, if applicable run, we run the the normal
checks there as well because it's just ExecUpdate() if (resultRelInfo->ri_WithCheckOptions != NIL)
ExecWithCheckOptions(WCO_RLS_UPDATE_CHECK, resultRelInfo, slot, estate);
so I do indeed think that there's no point in layering RLS above
EXCLUDED.
Greetings,
Andres Freund
