Re: minor error message enhance: print RLS policy name when only one permissive policy exists
| От | Dean Rasheed |
|---|---|
| Тема | Re: minor error message enhance: print RLS policy name when only one permissive policy exists |
| Дата | |
| Msg-id | CAEZATCXmYtwb=8=cNCcFnq__EksVodTuWQYWVbDU_sKxUS3vaA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: minor error message enhance: print RLS policy name when only one permissive policy exists (Florin Irion <irionr@gmail.com>) |
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: