Reviewing defined row level security policies in PostgreSQL-9.5

Question

I have built the brand-new PostgreSQL-9.5 (alpha) and I am quite excited about the new feature of row level security. This promises to make multi-role access management quite a bit more straightforward.

As an example, I have so far used a model where a NOLOGIN role is owner of the database and all tables, views, functions, etc; and then create views to grant appropriate access to specific roles. All good and fine, but the views do proliferate. The new CREATE POLICY command on tables with ENABLE ROW LEVEL SECURITY look to be a cleaner alternative to reach the same end.

However, I have so far been unable to determine which tables are RLS-enabled and what policies are defined on them. (All of this after tables and policies have been defined, obviously.) Is there an easy way to identify established policies on RLS-enabled tables?

(There is also the long-awaited UPSERT and many more jsonb functions for those of you who are interested, as well as many performance improvements.)

Answer 1

Ok, figured it out. (Geez, is nobody using 9.5 yet???)

Question 1: Which tables have row level security?

The pg_class relation has a new column relrowsecurity boolean which is as straightforward as it looks:

SELECT oid, relname FROM pg_class WHERE relrowsecurity = 'true';

Question 2: Which policies are defined on RLS-enabled tables?

The system catalog has a new relation pg_policy which stores all the information on the policy, specifically the name of the policy, the oid of the table, the command it applies to, the roles (oid[]) to which the policy applies and the USING and WITH CHECK clauses.

Interestingly, the latter two are stored as a pg_node_tree which is merged with the execution plan of the query subject to the policy so the condition(s) of the policy are not re-evaluated on every call. That makes this approach potentially faster than using views as elaborated in the question, because fewer clauses have to be parsed and evaluated for each call.