Hey Alexander, Looks like your latest patch addresses the original issue I posted!
So now I can create a placeholder with the USERSET modifier without a superuser, while non-USERSET placeholders still require superuser: ```sql create role foo noinherit; set role to foo; alter role foo set prefix.bar to true user set; ALTER ROLE alter role foo set prefix.baz to true; ERROR: permission denied to set parameter "prefix.baz" set role to postgres; alter role foo set prefix.baz to true; ALTER ROLE ``` Also USERSET gucs are marked(`(u)`) on `pg_db_role_setting`: ```sql select * from pg_db_role_setting ; setdatabase | setrole | setconfig -------------+---------+-------------------------------------- 0 | 16384 | {prefix.bar(u)=true,prefix.baz=true} ``` Which I guess avoids the need for adding columns to `pg_catalog` and makes the "fix" simpler. So from my side this all looks good! Best regards, Steve On Sun, 20 Nov 2022 at 12:50, Alexander Korotkov <aekorot...@gmail.com> wrote: > .On Sun, Nov 20, 2022 at 8:48 PM Alexander Korotkov > <aekorot...@gmail.com> wrote: > > I've drafted a patch implementing ALTER ROLE ... SET ... TO ... USER SET > syntax. > > > > These options are working only for USERSET GUC variables, but require > > less privileges to set. I think there is no problem to implement > > > > Also it seems that this approach doesn't conflict with future > > privileges for USERSET GUCs [1]. I expect that USERSET GUCs should be > > available unless explicitly REVOKEd. That mean we should be able to > > check those privileges during ALTER ROLE. > > > > Opinions on the patch draft? > > > > Links > > 1. > https://mail.google.com/mail/u/0/?ik=a20b091faa&view=om&permmsgid=msg-f%3A1749871710745577015 > > Uh, sorry for the wrong link. I meant > https://www.postgresql.org/message-id/2271988.1668807...@sss.pgh.pa.us > > ------ > Regards, > Alexander Korotkov >