Reading an AI Input Row Does Not Permit Every Replacement

Define the change the curation role must be allowed to make

A buyer evaluating an AI data-curation platform may need an operator to inspect several collections while changing values only within its assigned collection. An offer of read and update access leaves that distinction unresolved. Reading a row, selecting it as a change candidate and allowing its proposed replacement are separate decisions.

PostgreSQL 18 row-security policies supplement ordinary privileges. The relevant command and role determine which policies apply. For a regular UPDATE, USING concerns the existing row; WITH CHECK concerns the proposed row. A false or null check can therefore exclude an old candidate or reject a replacement at a different point.

The following example explains the proposed behavior without supplying SQL, configuration instructions or a security test. Its collection names are fictional data attributes, not established tenant boundaries.

References: [PG-R][PG-P]

ROW-28: two readable rows, one update scope

Fictional role U curates a table with two rows. R1 has collection A and value 10. R2 has collection B and value 20. Both are visible to U under an applicable SELECT policy that permits both rows, including the proposed rows considered below.

Stipulate that U has the required table and column privileges, row-level security is enabled, and U is an ordinary role subject to it: U is not the table owner, a superuser or a role with BYPASSRLS. Exactly one applicable permissive UPDATE policy is present. Its existing-row condition requires collection A. Its replacement-row condition separately requires collection A. No other applicable policy or row-changing trigger alters these premises, and all other relevant constraints are satisfied.

Compare three alternative ordinary updates independently from the original two-row state. Each attempts to change exactly its named row; the alternatives are not a sequence. SELECT visibility is deliberately permissive here so the second alternative isolates the replacement check instead of introducing a different read-policy failure. No database execution, commit or application effect is represented.

The same starting row can support one replacement and reject another

Alternative 1 targets R1 and proposes collection A, value 11. Its old collection A satisfies USING. Its proposed collection A satisfies WITH CHECK. Both row-policy gates pass under the premises. This supports the proposed within-collection edit at those gates; it is not an observed successful update.

Alternative 2 also targets R1 and proposes value 11, but changes its collection to B. The same old row still satisfies USING. The proposed replacement fails WITH CHECK because its collection is B. Under these premises, the command is rejected. Permission to select R1 as an update candidate has not supplied permission to transfer its collection identity.

The value change is identical in the two alternatives: 10 becomes 11. Their different row-policy conclusions arise from the proposed collection, not from whether 11 is numerically close to 10. A report that shows only the old-row permission would conceal that difference.

References: [PG-P]

R2 can be readable while remaining outside this update

Alternative 3 targets R2 and proposes collection B, value 21. R2's old collection B does not satisfy this UPDATE policy's USING condition. The ordinary update therefore does not reach it as an eligible candidate. The replacement check does not make an ineligible old row available.

U can still read R2 under the separate SELECT premise. Reading its value 20 is consistent with lacking this particular update permission. Conversely, R2's absence from an update result would not establish that the row was deleted, missing from the table or inaccessible to every other role.

This reconciles three useful outputs for the buyer: two visible rows, one eligible old row under the defined update policy, and a permitted replacement only when the new collection remains A. The counts describe different populations. Calling all readable rows editable would expand the offered behavior; calling collection A editable would still leave the allowed replacement values to explain.

A policy excerpt needs its role and composition context

ROW-28 fixes the policy context so its two gates can be followed. Real offers need that context established. PostgreSQL normally lets table owners bypass row security; superusers and BYPASSRLS roles also bypass it. The name curation user does not establish the privileges of the actual connection role.

Applicable permissive policies combine with OR; restrictive policies combine with AND, with a passing permissive basis also required. Adding a policy can therefore change the effective result. For ALL or UPDATE policies, an omitted WITH CHECK reuses USING. Omitting the written clause does not establish an unrestricted replacement. SELECT policies can also apply to updates that require SELECT permission.

Ask the appointed database and security owners to explain the effective behavior for the actual role and operation. One favourable policy expression cannot establish it in isolation. ROW-28 supplies no claim about a deployed policy set, privileged maintenance paths, indirect information exposure or complete tenant isolation.

References: [PG-R][PG-P]

Buy the intended edit boundary, with its outcome evidence

Suppose the buyer's stated requirement is to let U inspect A and B, edit values within A, and leave collection transfers outside U's authority. Offer Read demonstrates only that both original rows can be viewed. That answers the inspection requirement while leaving both parts of the update decision unaddressed.

Offer Old identifies the collection-A existing-row rule and explains why R1 is a candidate while R2 is not. It advances the explanation, but leaves alternative 2 open unless it also establishes the proposed-row rule. A form that hides the collection field would describe the form's behavior, rather than establish what the database role is permitted to submit.

Offer Pair connects the role, applicable privilege and policy context to all three alternatives. It explains the A-to-A pass, the A-to-B rejection and R2's exclusion while retaining R2's read visibility. Under the stipulated requirement, that is the complete row-policy explanation the buyer was missing. Evidence from the actual platform must still substantiate its delivered behavior.

Keep approval of a proposed row separate from the final application result. A policy pair says which row changes may pass those gates; it does not demonstrate a committed transaction, completed downstream AI extraction or correct business outcome. The related snapshot guide asks which committed versions an extraction sees. The SQL NULL guide asks which values a predicate or aggregate counts. Neither replaces the old-row/new-row authorization explanation.

A useful supplier response therefore carries the specific operation through both policy gates and names the team responsible for the actual implementation and outcome evidence. It does not stop at a generic secure-table label or borrow permission from a successful read.

Keep the equipment handoff separate from database access

If the wider platform project also needs physical compute or storage connections, Leviathan's Structured Cabling & Fiber Installation service provides a route to discuss agreed fiber and copper work, endpoint labels and connection records. Share the selected equipment, approved endpoints and routes, material responsibilities and required physical handoff through the related project inquiry.

That separate cabling scope does not supply database policy design or security acceptance. Those responsibilities remain with the appointed database, application and security providers.