Re: Granting SET and ALTER SYSTE privileges for GUCs
От | Andrew Dunstan |
---|---|
Тема | Re: Granting SET and ALTER SYSTE privileges for GUCs |
Дата | |
Msg-id | 1500eb6d-fb8f-acd2-b39e-c3ccaf7e3f1b@dunslane.net обсуждение исходный текст |
Ответ на | Re: Granting SET and ALTER SYSTE privileges for GUCs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Granting SET and ALTER SYSTE privileges for GUCs
Re: Granting SET and ALTER SYSTE privileges for GUCs |
Список | 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
В списке pgsql-hackers по дате отправления: