Re: ON CONFLICT issues around whole row vars,

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