Dean Rasheed <> writes:
> On 11 September 2015 at 15:49, Tom Lane <> 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.
Also, the unique-index problem only applies if there's a relevant unique
index, which doesn't necessarily have anything at all to do with the RLS
filter condition.

I think this is coming back to Robert's concern, that it is far from clear
that we understand the interactions of per-command RLS policies well
enough to ship them.  Maybe we should rip that out for 9.5 and only allow
a single RLS policy that that's the same for all commands.  We can always
add the more general facility later.

> 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.

I understand your concern about that, and it's reasonable.  But that
just leads me to the conclusion that maybe our ideas in this area are
not fully baked.

                        regards, tom lane

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

Reply via email to