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-25 16:06:05 |
Message-ID: | aFwebUErRdEKZy6i@nathan |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Here is a tidied-up version of the patch. It's still quite fragile, but
AFAICT to do any better we'd need to return more context from
find_option(), and I don't think we can change that one on the
back-branches since it's exported. I assume we don't want find_option() to
create a placeholder in this case, either. I'll continue to look around
for a better solution...
If we wanted to open up RESET in this case to everyone with suitable
privileges on the target DB and/or role (as proposed by Tom upthread [0]),
I think we'd just need to replace the "return false;" under find_option()
to "return reset_custom;".
[0] https://postgr.es/m/2474668.1750451081%40sss.pgh.pa.us
--
nathan
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Allow-resetting-unknown-custom-GUCs-with-reserved.patch | text/plain | 2.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-06-26 18:37:57 | Re: BUG #18953: Planner fails to build plan for complex query with LATERAL references |
Previous Message | Karl O. Pinc | 2025-06-25 14:42:06 | Re: PGXS does not properly uninstall documentation |