Phase 2.5: Row-level security policy visibility

[aesslinger]

Part of the Phase 2 set of PostgreSQL-specific features beyond the built-in driver.

Problem

Row-level security (RLS) policies are invisible in Tabularis today. A table can silently restrict which rows a role sees or can modify, but nothing in the UI surfaces that a policy exists — someone debugging "why don't I see any rows" or "why did my update affect 0 rows" has to already know to go check pg_policy by hand.

Proposed approach

SELECT polname, polcmd, polroles, pg_get_expr(polqual, polrelid) as using_expr,
       pg_get_expr(polwithcheck, polrelid) as check_expr
FROM pg_policy WHERE polrelid = $1::regclass;

Frontend integration

In the table detail panel, add a "Security Policies" section. Each policy shows: name, command (SELECT/INSERT/UPDATE/DELETE/ALL), roles, and the USING/WITH CHECK expressions.

Security considerations

USING/WITH CHECK expressions can reveal internal security-rule logic (e.g. "rows visible only where tenant_id = current_setting('app.tenant')") that shouldn't be exposed to every user of a shared connection. Only show this panel to the connection owner or a superuser role — gate it the same way other privileged-metadata views in this plugin are gated.

Acceptance criteria

• Policies on a table with RLS enabled are listed correctly, including command type and roles
• USING/WITH CHECK expressions render as readable SQL, not raw internal representations
• Policy visibility is gated to connection owner/superuser, not shown to every connected role
• No regressions in existing Phase 1 parity tests

Tests

• test_get_policies — lists policies on a table with RLS enabled
• test_policy_per_command — distinguishes SELECT vs UPDATE policies

References

• Full spec: docs/planning/03-phase-2-issue-16.md (2.5)
• Priority: Sprint 5 — medium demand, straightforward