public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: David G. Johnston <[email protected]>
Cc: richard coleman <[email protected]>
Cc: 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 12:33:49 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAKFQuwZducmkxoyh_=gvdHJ2Te5rHGctv70BQQsacmgMMjtZRw@mail.gmail.com>
References: <CAGA3vBug6Sq_XYLxzmY470WFS6Z3OF28goYzX=QHrCc4hgQSDw@mail.gmail.com>
<[email protected]>
<CAGA3vBuWjNdz=zfMNvpqYRJRdQCapbexWnD4kgOss2PMbw5ZZw@mail.gmail.com>
<[email protected]>
<CAGA3vBtp2H4+v-AnWLq_w8TVAuHS5++6dHW98YN1-q7N66ywYQ@mail.gmail.com>
<CAKFQuwZducmkxoyh_=gvdHJ2Te5rHGctv70BQQsacmgMMjtZRw@mail.gmail.com>
"David G. Johnston" <[email protected]> writes:
> Fundamentally making group-role memberships per-database is a fundamental
> change that seems quite unappealing to attempt without a solid use case
> that it will enable.
Yeah, I think this would be bad from both the intellectual-complexity
and implementation-difficulty standpoints.
However ... we've had multiple requests in the past to invent
database-specific roles. I wonder if it'd suffice for Richard's
purposes to create such roles and grant them pg_read_all_data.
You can sort of do that today, in that you can muck with pg_hba.conf
or database CONNECT privileges to limit which DBs a role can log into.
But either answer works only at initial login; they don't constrain
SET ROLE, so they're not really adequate for permissions-limiting
purposes. I'm imagining a feature whereby a database-specific role
is flat out not available in other databases; can't SET ROLE to it,
can't GRANT privileges (at least on non-shared objects) to it.
Probably role membership would still be nominally global, but it
wouldn't matter if you couldn't use the role.
This might still not pass the too-much-complexity test, but it
has the advantage of being something that there's been multiple
requests for.
regards, tom lane
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], [email protected], [email protected]
Subject: Re: database specific pg_read_all_data / pg_write_all_data
In-Reply-To: <[email protected]>
* 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