PostgreSQL's Row Level Security (RLS) enables fine-grained, policy-based access control at the row level. Master USING clauses, WITH CHECK constraints, permissive vs restrictive policies, and role-targeted policies for secure multi-tenant database applications.
0 / 5 completed
1 / 5
A PostgreSQL table has ALTER TABLE documents ENABLE ROW LEVEL SECURITY; applied. What happens to queries on this table by non-superuser roles?
When Row Level Security (RLS) is enabled on a table, non-superuser roles see no rows by default unless a policy explicitly grants access. This is the secure default ("default-deny"). Superusers and table owners bypass RLS unless ALTER TABLE ... FORCE ROW LEVEL SECURITY is also applied.
2 / 5
A RLS policy is created with USING (owner_id = current_user_id()). What does the USING clause control?
The USING clause in an RLS policy defines the row filter for reading operations: SELECT, UPDATE (rows eligible to be updated), and DELETE (rows eligible to be deleted). Only rows where the USING expression evaluates to true are visible or affected by these operations.
3 / 5
What is the purpose of the WITH CHECK clause in a PostgreSQL RLS policy?
The WITH CHECK clause applies to write operations (INSERT and UPDATE). It ensures that newly inserted or updated rows satisfy the policy condition — preventing users from writing data they wouldn't be able to read back. If a row fails the WITH CHECK expression, the write is rejected with an error.
4 / 5
A policy is created with CREATE POLICY ... TO app_user USING (true);. What does the TO app_user clause specify?
The TO clause in CREATE POLICY specifies which roles the policy applies to. If omitted, it defaults to PUBLIC (all roles). By targeting specific roles, you can create different policies for different user types — e.g., a permissive policy for app_user and a restrictive one for readonly_user.
5 / 5
Two RLS policies both apply to SELECT queries for the same role: one uses PERMISSIVE (default) and another is also PERMISSIVE. How does PostgreSQL combine them?
Multiple PERMISSIVE policies for the same command/role are combined with OR logic: a row is visible if it satisfies any of the permissive policies. RESTRICTIVE policies, by contrast, are ANDed — all restrictive policies must pass. The final result ANDs permissive (OR-combined) with restrictive (AND-combined) policies.