| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | mert(at)futo(dot)org, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #18964: `ALTER DATABASE ... RESET ...` fails to reset extension parameters that no longer exist |
| Date: | 2025-06-20 21:20:25 |
| Message-ID: | aFXQmZ2sveFAwdjY@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2025-06-20 22:48:37 | Re: BUG #18964: `ALTER DATABASE ... RESET ...` fails to reset extension parameters that no longer exist |
| Previous Message | Bruce Momjian | 2025-06-20 20:41:16 | Re: Index Rebuild Bug fixed in 14.6.7 |