public inbox for [email protected]  

help / color / mirror / Atom feed

From: richard coleman <[email protected]>
To: Laurenz Albe <[email protected]>
Cc: Pgsql-admin <[email protected]>
Subject: Re: database specific pg_read_all_data / pg_write_all_data
Date: Wed, 10 Dec 2025 09:10:29 -0500
Message-ID: <CAGA3vBtp2H4+v-AnWLq_w8TVAuHS5++6dHW98YN1-q7N66ywYQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAGA3vBug6Sq_XYLxzmY470WFS6Z3OF28goYzX=QHrCc4hgQSDw@mail.gmail.com>
	<[email protected]>
	<CAGA3vBuWjNdz=zfMNvpqYRJRdQCapbexWnD4kgOss2PMbw5ZZw@mail.gmail.com>
	<[email protected]>

Laurenz,

Running many clusters on a single server, while possible, reduces the
amount of memory available to each cluster and each database process users
run respectively.

ALTER DEFAULT PRIVLIGES doesn't work on schema that doesn't exist at that
time that command was run.

I am sorry to hear that you think "pg_read_all_data" is ugly.  That
built-in role and others like it have proven very useful for a fairly
common use case; a small group of users that must share database objects
between them without having to constantly rejigger privileges on those
objects.

In the rare case where a group has their own database cluster it has saved
a lot of work.  Sadly, it is unable to be utilized on shared clusters
hosting dozens of databases for different groups in its current form.

I hope that the PostgreSQL devs revisit it in the future with an eye
towards making it applicable in more situations.

Thanks for you input,
rik.



On Wed, Dec 10, 2025 at 8:10 AM Laurenz Albe <[email protected]>
wrote:

> 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
>

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: database specific pg_read_all_data / pg_write_all_data
  In-Reply-To: <CAGA3vBtp2H4+v-AnWLq_w8TVAuHS5++6dHW98YN1-q7N66ywYQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox