On 11/16/21 14:48, Mark Dilger wrote:
>
>> On Nov 16, 2021, at 8:44 AM, Tom Lane <tgl@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
toGRANT commands. That also handles the issues of extension upgrades, which I think the old patch handled better than
thediscussion 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