Re: database specific pg_read_all_data / pg_write_all_data - Mailing list pgsql-admin

From Laurenz Albe
Subject Re: database specific pg_read_all_data / pg_write_all_data
Date
Msg-id 8536f893e79693bd0a23d4cea7dbe0b6366378df.camel@cybertec.at
Whole thread Raw
In response to Re: database specific pg_read_all_data / pg_write_all_data  (richard coleman <rcoleman.ascentgl@gmail.com>)
Responses Re: database specific pg_read_all_data / pg_write_all_data
List 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 by date:

Previous
From: richard coleman
Date:
Subject: Re: database specific pg_read_all_data / pg_write_all_data
Next
From: Ron Johnson
Date:
Subject: Re: migrate oracle TH8TISASCII to postgres equivalnt win874