On Tue, 11 Nov 2025 at 22:00, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>
> 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
>
>
HI! I can see that review comment from Dean (about desirability of
patch) is not covered, so I changed [0] status to WOA
I also think the CF entry name is too long and it could be beneficial
to shorten it.
[0] https://commitfest.postgresql.org/patch/6180/
--
Best regards,
Kirill Reshke
