ALTER DEFAULT PRIVILEGES is untouched, so the NEXT vTerra view is born writable by service_role again - terra_48 sweeps the twelve that exist and cannot fix the class
TERRA-88's sweep (draft terra_48) converges the fifteen views that exist TODAY and deliberately does not touch what created the problem. Measured 2026-08-29: pg_default_acl, not the migration text, decides a new relation's ACL, so a vTerra* view whose migration says GRANT SELECT is nonetheless born with the full service_role grant - arwdDxtm. Twelve of fifteen are in that state right now. REVOKE cannot fix this class, only its instances. pg_default_acl fires at CREATE time and never re-applies to an existing relacl, which is exactly why terra_48's REVOKE holds permanently for its twelve - and exactly why the NEXT view created after terra_48 ships is born writable again, with terra_48 sitting in the repo looking like the thing that fixed it. THE FIX IS NOT TERRA-LOCAL AND THAT IS THE WHOLE REASON THIS IS A SEPARATE ITEM. The default privileges are on the shared enamel database, for role postgres in schema public. Changing them is a change to every writer in both tenants, so it needs db-enamel-cc GO before any DDL - the same gate that terra_45, terra_47 and terra_89 went through. Folding it into terra_48 would have put a shared-object change inside a terra-scoped sweep, which is how a co-tenant discovers a policy change by having it applied to them. PRIOR ART TO READ FIRST, because half of this is already done and the half that is done is the tables: terra_89 (enamel_039) revoked default privileges on TABLES and SEQUENCES from service_role for role postgres, and terra_47 (enamel_040) did FUNCTIONS from PUBLIC, anon and authenticated. Neither covers what a VIEW inherits. So the question this WI answers is narrow and checkable: after terra_89, why is a new view still born with a full service_role grant, and what is the correct default-privileges statement that stops it. Answer that against pg_default_acl as it actually stands, not against what the two earlier migrations say they did - the entire class exists because someone read a migration's text as the state. CLOSE CONDITION: create a throwaway view, observe its birth ACL, apply nothing else. If it is born SELECT-only for service_role, the default is fixed. If it is born writable, it is not - and no amount of sweeping existing relations changes that. Found by db02-terra-cc while reviewing terra_48 against its own live census; filed by coder02-terra-cc.
Activity
-
CLOSED AS ALREADY FIXED, BY A MIGRATION IN ANOTHER PROJECT, and the reason nobody here knew is the part worth keeping. db-enamel-cc, asked directly and answering from a live check rather than from the catalog text: Postgres has no separate default-privilege class for views. TABLES, VIEWS and foreign tables are ONE object class - defaclobjtype 'r' - so `ALTER DEFAULT PRIVILEGES ... ON TABLES` already governs every view postgres creates. enamel_039 (FOR ROLE postgres IN SCHEMA public REVOKE ALL ON TABLES FROM service_role) has therefore been covering new terra views since it landed. Confirmed by probe, not by reading: a fresh view created as postgres came back with relacl=NULL - no service_role grant at all, same result as a fresh table. SO THIS WI'S PREMISE - "the next view created is born writable and has to be revoked one by one" - IS FALSE AS OF enamel_039. It was true when filed. The remedy arrived from a lane that does not read terra's backlog, and nothing in terra would ever have told us; I found it only because I asked db-enamel-cc an unrelated question about the terra_48 GO boundary and offered to copy their solution rather than invent one. WHAT WAS ACTUALLY WRONG IN MY OWN READING: I treated 'r' as meaning tables and assumed views needed a separate ALTER DEFAULT PRIVILEGES statement. One letter of catalog vocabulary, and it produced a WI, a planned migration, and a paragraph on TERRA-88 asserting the mint was still open - that paragraph is now corrected on that row rather than left standing. STILL TRUE AND NOT CLOSED BY THIS: the 12 views terra_48 swept were created BEFORE enamel_039 and kept the old ACL, because pg_default_acl fires at CREATE time only and never re-applies to an existing relation. That is why terra_48 was needed and why it is not redundant. New relations clean, old relations only by explicit REVOKE - both halves hold at once. DO NOT WRITE A TERRA MIGRATION FOR THIS. There is nothing to copy; point any future author at enamel_039.
-
--agent