Hi! I'd like to resume this discussion.
On Wed, Jul 20, 2022 at 6:50 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Kyotaro Horiguchi <horikyota....@gmail.com> writes: > > At Tue, 19 Jul 2022 09:53:39 -0700, Nathan Bossart > > <nathandboss...@gmail.com> wrote in > >> Hm. I would expect ALTER ROLE to store the PGC_SUSET context when executed > >> by a superuser or a role with privileges via pg_parameter_acl. Storing all > >> placeholder GUC settings as PGC_USERSET would make things more restrictive > >> than they are today. For example, it would no longer be possible to apply > >> any ALTER ROLE settings from superusers for placeholders that later become > >> custom GUCS. > > > Returning to the topic, that operation can be allowed in PG15, having > > being granted by superuser using the GRANT SET ON PARMETER command. > > I think that 13d838815 has completely changed the terms that this > discussion needs to be conducted under. It seems clear to me now > that if you want to relax this only-superusers restriction, what > you have to do is store the OID of the role that issued ALTER ROLE/DB SET, > and then apply the same checks that would be used in the ordinary case > where a placeholder is being filled in after being set intra-session. > That is, we'd no longer assume that a value coming from pg_db_role_setting > was set with superuser privileges, but we'd know exactly who did set it. This makes sense. But do we really need to store the OID of the role? validate_option_array_item() already checks if the placeholder option passes validation for PGC_SUSET. So, we can just save a flag indicating that this check was not successful. If so, then the value stored can be only used for PGC_USERSET. Do you think this would be correct? ------ Regards, Alexander Korotkov