| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Granting SET and ALTER SYSTE privileges for GUCs |
| Date: | 2021-11-17 14:31:40 |
| Message-ID: | 1500eb6d-fb8f-acd2-b39e-c3ccaf7e3f1b@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/16/21 17:12, Tom Lane wrote:
>
>>> To support pg_dump and pg_upgrade, it might be better to have an
>>> enabled/disabled flag rather than to delete rows.
>> I'm not really sure what this means.
> I didn't see the point of this either. We really need to KISS here.
> Every bit of added complexity in the catalog representation is another
> opportunity for bugs-of-omission, not to mention a detail that you
> have to provide mechanisms to dump and restore.
>
>
Well, I was trying (perhaps not very well) to imagine how to deal with
someone modifying the permissions of one of the predefined roles. Say
pg_foo has initial permission to set bar and baz, and the DBA removes
permission to set baz. How is pg_dump going to emit the right commands
to allow a safe pg_upgrade? Maybe we should say that the permissions for
the predefined roles are immutable, so only permissions sets for user
defined roles are mutable.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2021-11-17 14:42:44 | Re: Printing backtrace of postgres processes |
| Previous Message | Xiaozhe Yao | 2021-11-17 14:28:53 | Re: Propose a new hook for mutating the query bounds |