Review old-row and proposed-row policies before AI record updates

Choose a mutation question that a read-only review cannot answer

A report can correctly hide another workspace yet leave unanswered what a later update may store. This guide reviews one fictional PostgreSQL 18 profile: an authenticated Cedar editor has separately approved changing draft D7 from Draft A to Draft B. The application authorizes the Cedar/D7 object before choosing its dedicated database identity. A trusted fixed operation changes only the title; the model supplies neither SQL nor table, column, role or policy names.

The reviewed documentation identifies PostgreSQL 18, without establishing a patch release or installed database. This is a symbolic review contract, not executable SQL or a deployment recipe. Its small base table has Cedar/D7 and Maple/D7 records, both initially titled Draft A. Local identifier D7 alone does not identify the workspace. The fixed operation selects that identifier under the dedicated Cedar role, making its row-policy boundary explicit rather than assuming identifiers provide authorization.

Make the privilege gate reachable and narrow

Propose database connection and schema lookup prerequisites, SELECT on identifier, workspace and title, and UPDATE on title alone. Require no other effective update grant, grant option, role membership or owner authority. PostgreSQL documents column-specific privileges and the SELECT rights needed when an update reads existing values. PostgreSQL 18 privileges

A request containing a workspace edit fails the application’s fixed-field contract before database dispatch. A statement assigning that column would also lack the declared column privilege. Neither case demonstrates execution of WITH CHECK. Record the earliest failed gate, rather than crediting every downstream control. If effective privileges cannot be established, hold the profile; a direct grant list alone is insufficient evidence.

Write separate existing-row and proposed-row questions

With RLS enabled, propose one permissive SELECT policy for Cedar rows and one permissive UPDATE policy: existing-row USING requires Cedar; proposed-row WITH CHECK requires Cedar and a title in the invented set {Draft A, Draft B}. No ALL, PUBLIC or additional policies apply in this fixture. These predicates are policy notation, not installed definitions. Row security examples illustrate separate visibility and modification expressions.

The fixed operation reads the identifier, so the SELECT side matters too. UPDATE USING filters existing rows; WITH CHECK evaluates proposed contents and rejects false or null with an error. Omitting WITH CHECK on UPDATE falls back to USING. CREATE POLICY defines these distinctions. An omitted new-row expression therefore does not mean “no new-row test,” but it would lose this fixture’s separate title restriction.

Keep one useful positive path in the review sheet

Label the proposed edit E-A and the reviewed profile P-A. Under P-A, Cedar/D7 is visible and eligible; the Maple/D7 counterpart is excluded. The proposed Cedar/D7 row retains Cedar and has title Draft B, satisfying the declared new-row rule. That is the intended permitted edit. Nothing was submitted, and no row count, commit or persistence result was observed.

Record five separate entries: authenticated application object; fixed allowed field; effective role and grants; complete SELECT/UPDATE policy inventory; expected old and proposed row values. This prevents a reviewer from replacing “the proposed row satisfies the rule” with “the old row was visible.” A real implementation would additionally need independent evidence that its command, connection identity and object definitions actually match this sheet.

Use eight inert cards to expose wrong conclusions

The Reserved card deliberately changes an editable title, making the new-row question reachable. Changing workspace privileges to demonstrate a different result would create a different configuration, not validate P-A.

Review policy composition and privileged exceptions explicitly

Within a policy type, applicable permissive expressions combine with OR, restrictive expressions with AND; at least one permissive policy must pass. Required SELECT and UPDATE policy types combine with AND. Policy composition rules make a single reassuring predicate an incomplete review.

Superusers and BYPASSRLS roles bypass RLS. Owners normally bypass it; FORCE can subject the owner, without removing the other exemptions. Enabled RLS with no applicable policy denies row access. Row security applicability supplies those limits. P-A excludes privileged execution rather than claiming FORCE fixes every role. Unknown membership, views, triggers, definer functions or cross-table policy lookups require a new review; none is silently included.

Separate the worksheet from enforcement evidence

This worksheet does not settle concurrency, connection-pool cleanup, transaction success or side effects. PostgreSQL also warns that referential-integrity checks bypass row security and can reveal existence information. RLS limitations preclude a universal isolation claim.

All eight cards and the positive edit are proposed and unrun: no SQL, database connection, query, policy, grant, schema, configuration or candidate runtime experiment occurred. Boundary is a prelaunch model router with planned request-path checks, not a shipped PostgreSQL authorization service. The available synthetic action exercise and mock evidence concern different controls; they provide no database enforcement result.