On 11 September 2015 at 15:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dean Rasheed <dean.a.rasheed@gmail.com> 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.
>
That's what I was suggesting, except I was advocating a throw-error
result rather than a nothing-happens result.
Regarding the possibility of leaking info about the existence of rows,
that's something that already happens with INSERT if there are unique
indexes, and we've effectively decided there is nothing we can do
about it. So I don't buy that as an argument for doing nothing over
throwing an error.
My concern about doing nothing is how confusing it might be that an
UPDATE without RETURNING might update more rows than an UPDATE with
RETURNING and an identical WHERE clause. Throwing an error is much
more explicit about why you can't return those rows.
Ultimately I think this will be an extremely rare case, probably more
likely to happen as a result of accidentally misconfigured policies.
But if that does happen, I'd rather have an error to alert me to the
fact, than to silently do nothing.
Regards,
Dean