Re: database specific pg_read_all_data / pg_write_all_data
| От | Laurenz Albe |
|---|---|
| Тема | Re: database specific pg_read_all_data / pg_write_all_data |
| Дата | |
| Msg-id | 8536f893e79693bd0a23d4cea7dbe0b6366378df.camel@cybertec.at обсуждение исходный текст |
| Ответ на | Re: database specific pg_read_all_data / pg_write_all_data (richard coleman <rcoleman.ascentgl@gmail.com>) |
| Ответы |
Re: database specific pg_read_all_data / pg_write_all_data
|
| Список | pgsql-admin |
On Wed, 2025-12-10 at 08:06 -0500, richard coleman wrote: > Multiple clusters would be nice, but we don't have the available servers to accomodate that. You can run many clusters on a single server... > Without the pg_read_all_data role there is apparently no other way in PostgreSQL to > automatically assign these privs to each and every table/view that exists or will be > created without using the nuclear option and granting super user privs. > Unless there is something else that I am missing which could be used when creating your > suggested "readonly_dbname" role. Yes, and that is ALTER DEFAULT PRIVILEGES. > It's a shame that PostgreSQL has created some extremely useful built in roles, but then > limits them such that they can only be utilized for vanishingly few actual use cases. > > Hopefully the PostgreSQL devs revisit these built in roles with a thought toward making > database specific ones assignable with a mechanism like: > > grant pg_read_all_data on database foo to user_role; Frankly, I think that "pg_read_all_data" is ugly and should never have been added. Yours, Laurenz Albe
В списке pgsql-admin по дате отправления: