Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
От | Christophe Pettus |
---|---|
Тема | Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications |
Дата | |
Msg-id | 6860E1BC-DA5A-4576-9FB6-35ED31E6F017@thebuild.com обсуждение исходный текст |
Ответ на | BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
|
Список | pgsql-bugs |
> On Sep 6, 2024, at 16:44, Basha <Basha@maxcontact.com> wrote: > If shadowing system catalogs via views is not a recommended path, we would be grateful for guidance on alternative approachesto achieve the same result—restricting visibility of databases in a multi-tenant environment while maintainingessential operations like backups. Specifically, is there a supported way to enforce database isolation at thesystem catalog level, or is there a possibility of introducing a more granular control over pg_dump in such cases? The closest analogy that I've seen in the field is what Heroku does (did?) for database-based multitenancy, which is to assignvery random names to the databases, without revealing any client names or other human-readable data. That the databasesexisted was still visible in pg_database, but it leaked no substantial information to users connected to other databases.
В списке pgsql-bugs по дате отправления: