Re: Improving GUC prefix ownership for extensions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improving GUC prefix ownership for extensions
Date: 2026-02-11 16:58:48
Message-ID: 4114702.1770829128@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Wednesday, February 11, 2026, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
> wrote:
>> Thoughts, would this be a useful feature?

> I’d go with leaving well enough alone. How bad are the consequences of
> leaving this protection mechanism opt-in? Do we really want the grief of
> making it mandatory?

Making it mandatory is a non-starter, and the only thing that could
be even worse than that is having it GUC-controlled (remembering that
extension authors have to cope with all possible GUC settings).

I don't think this idea can fly. I'm also skeptical that there's any
real-world problem that needs solving here. I've not heard reports of
GUC prefix conflicts between extensions --- that would pretty much
imply an extension name conflict, which is problematic with or without
any GUCs. What MarkGUCPrefixReserved is really about is detecting
misspelled hand-made config-file entries and SET commands as best we
can. It's not perfect certainly, but I don't see that this proposal
makes that case better.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2026-02-11 17:01:02 Re: Fix pg_stat_get_backend_wait_event() for aux processes
Previous Message David G. Johnston 2026-02-11 16:44:23 Re: Improving GUC prefix ownership for extensions