Re: BUG #18964: `ALTER DATABASE ... RESET ...` fails to reset extension parameters that no longer exist
От | Nathan Bossart |
---|---|
Тема | Re: BUG #18964: `ALTER DATABASE ... RESET ...` fails to reset extension parameters that no longer exist |
Дата | |
Msg-id | aFXQmZ2sveFAwdjY@nathan обсуждение исходный текст |
Ответ на | Re: BUG #18964: `ALTER DATABASE ... RESET ...` fails to reset extension parameters that no longer exist (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Fri, Jun 20, 2025 at 04:24:41PM -0400, Tom Lane wrote: > In the case at hand, where the prefix is known but the parameter > isn't, I think we could safely assume that the setting is either > a mistake (probably installed while the extension wasn't loaded) > or the described case of a parameter the extension no longer > uses. Either way it seems safe to allow RESET with suitable > privileges on the target DB and/or role. I'm a little hesitant to consider opening this up too much. For example, what if someone accidentally downgrades the library temporarily and a GUC definition disappears, or one version of the library removes a parameter and a future one adds it back (due to user backlash)? Maybe those situations are too contrived/unlikely to worry about, though. > If the prefix is not known, then we're really flying blind. > It looks like we assume the parameter might be SUSET and therefore > allow both ALTER DB/ROLE SET and RESET only to superusers. > I'm hesitant to relax that case. IIUC we also check pg_parameter_acl in this case, but I agree that we don't want to relax this any further. -- nathan
В списке pgsql-bugs по дате отправления: