From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: if (!superuser) checks |
Date: | 2016-04-22 23:29:25 |
Message-ID: | 20160422232925.j7ocupa5w25ykinj@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2016-04-22 14:56:44 -0400, Stephen Frost wrote:
> The idea we came up with is to have a pg_replication default role which
> essentially replaces the REPLICATION role attribute. Andres didn't see
> it as being terribly valuable to disallow a role with the REPLICATION
> attribute from logging into the database directly, if it's allowed to do
> so by pg_hba.conf.
Not just not useful, but rather an anti-feature.
> Lastly, Andres felt that we could keep the syntax for
> setting/unsetting the role attribute and just convert those into
> GRANT/REVOKE statements for the pg_replication role. I'm not thrilled
> with that idea as it feels a bit unnecessary at this point, given the
> relatively few users of pg_logical_* functions by tools
Uh, that's not just about the pg_logical_ functions. It's primarily
about scripts which setup a postgres cluster, including replicas. Those
will frequently (hopefully at least) include creating/altering a role to
have the replication flag set?
> Andres, please correct me if any of the above is incorrect.
Nothing but the above point stands out.
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2016-04-23 00:24:53 | Re: pg_dump dump catalog ACLs |
Previous Message | Tom Lane | 2016-04-22 22:37:48 | Re: kqueue |