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


> 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)
slot, estate);
and before executing the actual projection we also checked the existing
                ExecWithCheckOptions(WCO_RLS_CONFLICT_CHECK, resultRelInfo,

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)
slot, estate);

so I do indeed think that there's no point in layering RLS above


Andres Freund

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to