On 11/16/21 14:48, Mark Dilger wrote: > >> On Nov 16, 2021, at 8:44 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> My concern is not about performance, it's about the difficulty of >> maintaining a catalog that expects to be a more-or-less exhaustive >> list of GUCs. I think you need to get rid of that expectation. > I'm preparing a new version of the patch that has the catalog empty to begin > with, and only adds values in response to GRANT commands. That also handles > the issues of extension upgrades, which I think the old patch handled better > than the discussion on this thread suggested, but no matter. The new > behavior will allow granting privileges on non-existent gucs, just as ALTER > ROLE..SET allows registering settings on non-existent gucs.
Your original and fairly simple set of patches used hardcoded role names and sets of GUCs they could update via ALTER SYSTEM. I suggested to you privately that a more flexible approach would be to drive this from a catalog table. I had in mind a table of more or less <roleid, guc_name>. You could prepopulate it with the roles / GUCs from your original patch set. I don't think it needs to be initially empty. But DBAs would be able to modify and extend the settings. I agree with Tom that we shouldn't try to cover all GUCs in the table - any GUC without an entry can only be updated by a superuser. To support pg_dump and pg_upgrade, it might be better to have an enabled/disabled flag rather than to delete rows. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
