On 11 September 2015 at 17:56, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dean Rasheed <dean.a.rasheed@gmail.com> writes:
>> On 11 September 2015 at 15:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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.
>
> Well, I don't buy your argument either. The unique-index problem means
> that if you have INSERT or UPDATE privilege, you can check for existence
> of a row conflicting with a row that RLS would let you insert or update.
> It does not mean that DELETE privilege would let you make that check.
OK, the unique-index argument wasn't the best argument. How about
this:- if you have the DELETE privilege you can already check for the
existence of any row that RLS would let you delete just by looking at
the command status. The same is true for UPDATE. So throwing an error
when attempting to use RETURNING to see a row that's not visible to
you doesn't leak any more existence info than before.
Regards,
Dean