Thread

Re: minor error message enhance: print RLS policy name when only one permissive policy exists

Dean Rasheed <dean.a.rasheed@gmail.com> — 2025-11-11T16:59:55Z

On Tue, 11 Nov 2025 at 14:10, Florin Irion <irionr@gmail.com> wrote:
>
> The change is relevant primarily when there is a single
> permissive policy, the most common case. When multiple policies are in place,
> the error message remains generic, which is appropriate.

I'm not entirely convinced that this is a good idea.

For one thing, permissive policies grant access to the table, rather
than denying it, so if the permissive policy checks fail, it's because
no permissive policy granted access, not because any particular policy
denied access. So in the special case where there happens to be
exactly one permissive policy, it's not really accurate to say that
one policy was violated.

For another thing, this patch doesn't help at all in more complex
cases, where there are multiple (or no) applicable policies, and
arguably it's those cases that would benefit most from an improved
error message. Trivial cases like the one cited at the start of this
thread don't really need much improvement, because there is only one
policy, so it's obvious where to look.

In my experience, one of the hardest parts about figuring out why a
RLS check failed is working out which type of policy check failed. For
example, in an INSERT ... ON CONFLICT DO UPDATE, it might have been an
INSERT policy check that failed for the row proposed for insertion,
but it might also have been an UPDATE or SELECT policy for a row being
updated. In fact, nearly all the commands check SELECT policies in
addition to the command-specific policies. So perhaps a better
approach would be to specify the policy command type in the error
message (adding that as a new field to the WithCheckOption struct).
For example, if the policy name is NULL (an OR'ed set of permissive
policy checks), report something like this:

ERROR:  new row violates row-level security policy for SELECT on table "tts"

Then you'd know to look at the SELECT policies, which might not
otherwise be obvious.

Regards,
Dean