| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, nathandbossart(at)gmail(dot)com, steve(at)supabase(dot)io, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Allow placeholders in ALTER ROLE w/o superuser |
| Date: | 2022-11-18 21:41:46 |
| Message-ID: | 2271988.1668807706@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
... BTW, re-reading the commit message for a0ffa885e:
One caveat is that PGC_USERSET GUCs are unaffected by the SET privilege
--- one could wish that those were handled by a revocable grant to
PUBLIC, but they are not, because we couldn't make it robust enough
for GUCs defined by extensions.
it suddenly struck me to wonder if the later 13d838815 changed the
situation enough to allow revisiting that problem, and/or if storing
the source role's OID in pg_db_role_setting would help.
I don't immediately recall all the problems that led us to leave USERSET
GUCs out of the feature, so maybe this is nuts; but maybe it isn't.
It'd be worth considering if we're trying to improve matters here.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-11-19 00:33:49 | Re: test/modules/test_oat_hooks vs. debug_discard_caches=1 |
| Previous Message | Justin Pryzby | 2022-11-18 21:37:31 | Re: fix stats_fetch_consistency value in postgresql.conf.sample |