Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vTKx9-0007Hq-0d for pgsql-admin@arkaria.postgresql.org; Wed, 10 Dec 2025 14:14:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vTKx7-00C03m-2m for pgsql-admin@arkaria.postgresql.org; Wed, 10 Dec 2025 14:14:02 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vTKtu-00BvTw-06 for pgsql-admin@lists.postgresql.org; Wed, 10 Dec 2025 14:10:42 +0000 Received: from mail-oa1-x32.google.com ([2001:4860:4864:20::32]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vTKts-00493F-1j for pgsql-admin@lists.postgresql.org; Wed, 10 Dec 2025 14:10:41 +0000 Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-3eae4e590a4so3415869fac.1 for ; Wed, 10 Dec 2025 06:10:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765375840; x=1765980640; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gupzfS15oU+G8TKx6zQVy6IRngbq9yQpGST7QZf1xaw=; b=XnBO4dMMd/2Nmv7HwBT/OU8FvsBf/YqP2RJoq/sfiMEmmfr4cNpphjp1CL5xpm/ENw ffQ8D+mhwhtfcZJVfSCWG/jHiuYG2/hQyqS39WUydk1L9CcwivFJI00kDFUy1hz9wboy a89Nyb/k4jVmQdPZ1cNjUtPqlCcJhjg9FDYiMugc3UeURPqibRV2HYOoJg9UQUVsuYFJ tNiQTVAN4E8kNO3gBtQI6yq8x0co1b/mlqjiNb68CMdyhXEWislDLODJE13efS9f4v8h g6+a5HDlagIiX24hhNg1892NVTeLFbGW7tWb54W3dgduD0OzFWkwxXUfN/sZu5uZiXsO yf/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765375840; x=1765980640; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gupzfS15oU+G8TKx6zQVy6IRngbq9yQpGST7QZf1xaw=; b=HjieKBAU8UzuhnAc0nV4zqG2FubVntmefsPQEIUDp8nqS8GX4UR9TfxH1+WUeznRoX tO1TrTaORspdmVDNWmxM5cc+55hFcv8I0hLxgBqLAPRi+iq+vB5/8Ouzy36E3wAkWXmv 59+GVPff4z0qg5SETGdS9QWE2MGKD7WkFq/6h2qruzTObfpu0et9P2d5vJ2qZ7WtePpq +Cos4cfK4INw2wsaLbQZk0VQVDXu6xq8PfqgyyUlDuYV5o5yncsyknrYYF9R+12MvlsB rXZ8jI87PJ6YM2BAqlP9wj2nIkmj3hI87ooSbxKqZ1wm95UwUdvfclsUX0rvKS7Pbchr 2pYw== X-Gm-Message-State: AOJu0Yy8vIS2Wg4UJ35OP8DvIx1Nyg9VeYEzsrvQKxYoYD/ZDO9Mzfyt xMoEshzQ00Ve1ucNOixATVrDD01DSp/oEluYX/PpUXVnwBs8H75PzV30lGxTqrNAk2JKck5eYVB K5Cri4GwuQ/Ve/oA2OmqU0x6XH2bDdaI= X-Gm-Gg: AY/fxX60G5wdLIDtjBE/YX27HhKWwEc0dz2hlAWVMHFXbjwPShzinvY6IZVqGMwkqU9 618wajhCktxaKMwgKT3fVhRvh4m9OKviAwrgApDvVn6gnsZ4eMZ5hrLJoJvjtKQNYtsdVV97VWR EcpWpj/bZWu9qcxNqd0gTxdhrpN8Fwdp3kYouBqj2I9fq+CJtyj0/s8lIVbRuBhE5EsguTB+nek KwG+acay4QH3eC219+Poilc84kLd21CeC9kg9DBP4RyJcpzvkDK/ZfYHq2ZMmavhE8i6x05dlFX 9JbDA80uixnxFbzXniMp3lo5//omh2RjoABTOlr4BGsRpQD319FJrF9i X-Google-Smtp-Source: AGHT+IHHnCCMj+D30XMG7bBmPEw5karGozgulB0HnMM7rmY/9xNVXvUGNxSl1e/tUtbMKdTLlJFFveehwz+ilRGnKjk= X-Received: by 2002:a05:6870:ff48:b0:3c9:8aa1:12a8 with SMTP id 586e51a60fabf-3f5bdc735e6mr1731566fac.25.1765375839843; Wed, 10 Dec 2025 06:10:39 -0800 (PST) MIME-Version: 1.0 References: <72acf8ae4e56886081b9f632569f290d3246c33b.camel@cybertec.at> <8536f893e79693bd0a23d4cea7dbe0b6366378df.camel@cybertec.at> In-Reply-To: <8536f893e79693bd0a23d4cea7dbe0b6366378df.camel@cybertec.at> From: richard coleman Date: Wed, 10 Dec 2025 09:10:29 -0500 X-Gm-Features: AQt7F2rGgOOJPRwrNEXhT9tteUF4Efx9AWcXBKJ4hdcn5JNMt2adhk1J16cT28A Message-ID: Subject: Re: database specific pg_read_all_data / pg_write_all_data To: Laurenz Albe Cc: Pgsql-admin Content-Type: multipart/alternative; boundary="000000000000d4385d0645999755" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d4385d0645999755 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Laurenz Albe 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 server= s > 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 > --000000000000d4385d0645999755 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Laurenz,

Running many clusters on a sin= gle 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 sor= ry to hear that you think "pg_read_all_data" is ugly.=C2=A0 That = built-in role and others like it have proven very useful for a fairly commo= n use case; a small group of users that must share database objects between= them without having to constantly rejigger privileges on those objects.=C2= =A0

In the rare case where a group has their own d= atabase cluster it has saved a lot of work.=C2=A0 Sadly, it is unable to be= utilized on shared clusters hosting dozens of databases for different grou= ps 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,
r= ik.



On Wed, Dec 10= , 2025 at 8:10=E2=80=AFAM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Wed, 2025-12-10 at 08:06 -0500, rich= ard coleman wrote:
> Multiple clusters would be nice, but we don't have the available s= ervers 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= =C2=A0 PostgreSQL to
> automatically assign these privs to each and every table/view that exi= sts 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 w= hen creating your
> suggested "readonly_dbname" role.=C2=A0

Yes, and that is ALTER DEFAULT PRIVILEGES.

> It's a shame that PostgreSQL has created some extremely useful bui= lt in roles, but then
> limits them such that they can only be utilized for vanishingly few ac= tual use cases.
>
> Hopefully the PostgreSQL devs revisit these built in roles with a thou= ght toward making
> database specific ones assignable=C2=A0 with a mechanism like:
>
> grant=C2=A0pg_read_all_data=C2=A0on database=C2=A0foo=C2=A0to=C2=A0use= r_role;

Frankly, I think that "pg_read_all_data" is ugly and should never= have been added.

Yours,
Laurenz Albe
--000000000000d4385d0645999755--