A Postgres role with no grants reads the FORCE flag on tables it cannot select from

pg_class and pg_namespace are readable by PUBLIC in a default install ^[10]. det_bare owns nothing and holds no grant at all on the three tenant tables, and it read their owner, relrowsecurity and relforcerowsecurity exactly ^{[6] [11]}. Catalog visibility was the open question in the comment thread, and it turned out not to be the problem ^[10]. The author wrote that a check answering nothing to report because it cannot see the tables would be worse than no check at all ^[3].

The condition being checked is narrow. A role that owns a table bypasses that table's row-level security policies unless the table has FORCE ROW LEVEL SECURITY ^[1], and CREATE DATABASE app_db OWNER app followed by doctrine:migrations:migrate leaves the serving role owning everything the migrations created ^[22]. @to21as proposed in the thread that a check does not have to impose FORCE or a separate role to be useful, and can simply report that the serving role owns the tenant tables with FORCE off ^[2].

The query's FROM is a VALUES list of public.organization, public.invoice and archive.audit_log, LEFT JOINed to pg_namespace on nspname and to pg_class on relnamespace and relname ^[8]. The LEFT JOIN is what makes an invisible table reportable: it comes back as a row with seen_in_catalog = false instead of no row at all ^[9].

to_regclass() writes the same lookup in less SQL, and under det_bare it raised ERROR: permission denied for schema archive, the schema the test deliberately placed outside the default search_path ^{[12] [5]}. information_schema.tables failed quietly: zero rows for det_bare, no error, because its views only show what the current role has some privilege on ^[13]. Of the three listing methods tried, only the join to pg_class by name returned three rows under all three roles ^[19].

For det_bare the information_schema verdict comes out right anyway, since det_bare owns nothing ^[16]. Those views cannot separate "there are no tenant tables here" from "I am not allowed to see them" from "the migrations never ran", so a check built on them loses its third outcome ^[17].

The catalog does not carry the table list. The check takes it from the application, in a Symfony app from the Doctrine metadata of the entities scoped by tenant ^[7]. A table that never reaches the VALUES clause produces no row in either query ^[21]. The author counts two remaining routes to a false "nothing to report", and says one of them no query can fix ^[18].