Dean Rasheed <> writes:
> Yeah, we had a similar discussion regarding UPDATE USING policies and
> ON CONFLICT UPDATE clauses. I think the argument against filtering is
> that the rows returned would then be misleading about what was
> actually updated.

It seems to me that it would be a horribly bad idea to allow RLS to act
in such a way that rows could be updated and then not shown in RETURNING.

However, I don't see why UPDATE/DELETE with RETURNING couldn't be
restricted according to *both* the UPDATE and SELECT policies,
ie if there's RETURNING then you can't update a row you could not
have selected.  Note this would be a nothing-happens result not a
throw-error result, else you still leak info about the existence of
the row.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to